Robot's orientation changes even if `angular_velocity` is forced to 0
Closed this issue · 2 comments
While trying to improve our high-level control of the robots, I encountered a weird error where the robot would still turn even if the logs showed that the angular_velocity of the command was set to 0. This only happens if I use the I factor of the PID controller I just implemented (for testing). You can change whether you use the P, I or D factor in the control in the code at line 155 on branch pid-moveto
You'll notice that I have forced the command to output 0. for the angular velocity of the robot. I don't know what is causing this, but I don't know enough about vector mathematics to understand what happens behind.
Found out that if you use the current version of the MoveTo action we had at the RoboCup, changing the GOTO_SPEED factor from 1.5 to 4.0 leads to the same orientation problems.
This might just come from the grSim simulator, so we should also try on the ERForce simulator
just tried launching the current MoveTo with GOTO_SPEED=83and dumped the orientation value of the robot in the console using aquarium. The orientation does not diverge as much as in grSim, maximum variation of the angle was about +/- 0.15 (the values I received ranged from -0.69 to -0.72 in radian) and the angle was automatically corrected during the command by the simulator (as I had the angular_velocity still forced to 0. on the current MoveTo). Perhaps we should start considering again about using the ERForce simulator as it seems to be much more precise when receiving the commands. I don't exactly know where this comes from though.
There is also a small deviation from the straight trajectory ordered to the robot, and it is more excessive in grSim than in the ERForce simulator for the same values and the same commands
TL; DR robot orientation varies by A LOT in grSim, but only by a variation of +/- 0.15 in the ERForce's simulator. Tested using current MoveTo and with parameter GOTO_SPEED=8.0 instead of default 1.5