Remote Visualizer Won't Connect

[Dave Kotfis]

We aren't seeing the remote visualizer connect to the controller. We have the controller running on CPU1, and the ROS API on CPU2. Our network config file allows these two to see each other. We are running the remote visualizer on our field computer (on the same subnet at the two perception machines). Is there any additional configuration that we need for the remote visualizer to find everything?

[DouglasS]

@dkotfis I cannot reproduce this. The only .ini file that is critical for this to work is the controller's .ini file, whose logger entry should be pointing either at a Logger if you're running one, or at some arbitrary IP address on the same subnet that the field computer's interface that can speak to CPU1 is. For example, our CPU1 has its field-facing IP set to 10.7.4.101, our Field Computer/OCU has IP address 10.7.4.41, and our Logger has IP address 10.7.4.46. The controller's .ini points at 10.7.4.46, but even if the Logger isn't running on that machine I can still connect a remote visualizer from the OCU.

We have also not tested the visualizer over the competition wireless link, and can't make any guarantees that it works there. As noted in the docs, the visualizer won't work during the competition due to bandwidth so we've made no attempt to test it over this link. We use one of the spare perception box switch ports to establish a 2nd hardwired "diagnostic" network between us and the robot for testing and development.

Another possible problem is if the outgoing interface (CPU1) has a larger MTU set than the receiving interface, but that's a general networking issue and not a bug in the visualizer. Double check that all your MTU's are equal, I believe all of the perception boxes default to 7200. If your field computer doesn't have a NIC that supports jumbo frames then you will need to decrease the MTU on CPU1.

[Dave Kotfis]

Ok, we weren't setting the logger correctly on the controller's .ini. It connects correctly now.

We're seeing all of the gains for the upper arms at zero, though the dithering parameters are filled in. Is this normal? The documentation suggests that a_k_q_p, etc. should be non-zero.

[DouglasS]

@dkotfis Glad that the visualizer is working. Those zeroes are definitely bugs, though; if the hydraulic arm gains file doesn't exist then it should use some defaults. Assigning to @georgwi

[Dave Kotfis]

The default file wasn't in the controller release in the place that it was looking for it, but we've got it pointed to our version of the gains file now (it reports loading the file successfully). We are still seeing all zero gains in the visualizer, though. err_int_abs_max and the dithering terms are set correctly, but all the gain terms are zero.

Is it possible they're just not displaying correctly? If they were truly zero, we wouldn't be able to move the arms at all?

[Steven Gray]

We just tried to set these gains (a_k_q_p, etc) manually using the visualizer. As soon as we set them, they get reset to 0.

[Georg Wiedebach]

I am really sorry for the confusion about this! The values you are setting when changing the values in the ll_out_* fields are the gains that are sent to the BDI low level controllers. We overwrite them and set them to zero every tick because we do not use the BDI low level controllers but out own PIDs. The only value we send to the BDI controllers should be the *_ff_const value and that one is the output of our PIDs plus a dither term.

If you want to tune the gains with the remote visualizer you will have to change a different set of values. For the left SHZ eg look for the variables *_JOINT_L_ARM_SHZ_PID there are the variables that you should be able to set. I will change the description in the ini file to be less confusing.

For the dither look for the variables controldither_* you should set the controldither_frequency_desired (this sets the frequency to the closest value that can be achieved with the control dt) and controldither_amplitude.

Also, yesterday a couple of people on our team retuned the arm gains because we saw oscillations and shaking (probably some of the same issues you are having). So in case you are not super excited about tuning the gains yourself you could give our gains another try with the next release :)

[Steven Gray]

Any chance you could tell us those gains now so we can give them a try?

[Georg Wiedebach]

We now switched to using a leaky integrator on the ELY and ELX (leak variable is 0.992 instead of 1.0). The ini file does not support loading that parameter yet. I will update the ini file so it loads the gains except the leaking but if you want to try the new set of gains before the release you will have to manually set the integral leak in the remote visualizer for the two joints above.

[Georg Wiedebach]

The ini file on the develop branch has the new default IHMC gains now if you want to try them