-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wheel reference tracking problem in simulation (undesired rolling) #12
Comments
The undesired rolling of the wheels during stance phases (constant position of a foot) is an important issue which may tightly related to the reference tracking issue during roll phases (see my previous comment). I recorded the amount of undesired rolling we have during the sequence of movements of our demo. Below you can see these errors for FR and HR wheel (from |
FYI @liesrock |
As suggested by @aled96, we could add an integral controller for the wheels and see if it improves anything.. |
After changing line 24 of https://github.com/ADVRHumanoids/iit-centauro-ros-pkg/blob/velodyne-realsense/centauro_urdf/urdf/gazebo/xbot.gazebo.xacro from: In fact I was able to step on/down a platform without experiencing the rolling problem. |
Implementing the integral controller will be even better, since there will be no need to send position references to the wheels (as is on the real platform)! |
Perfect, that would be great ! |
This eliminated undesired wheel rolling when I performed pure locomotin but has caused me some new problems. The wheels are not controlled properly when sending velocity references to the wheel joints through
|
As rolling of the simulated centauro has troubled me and other people quite a lot of times and this is a major issue that we cannot solve easily, I create this issue in order to share here some information which may be useful for anyone experiencing or tackling this problem.
Lately as part of implementing in simulation the scenario of our demo I have found some tracking errors of the wheel joints which in many cases lead to inaccurate tracking of cartesian trajectories by the wheel links. I conducted some simple rolling motion experiments using the branch demo-stepping of the model and this .config for the SoT. I, also, checked the effect of the motion duration (i.e. larger or lower wheel velocities) and the 2 different physics engines: ode and bullet. The simulations are done in this .world where some properties of the physics engines are defined.
Below you can see the errors of the wheels global positions (topic
/gazebo/link_states
) in the rolling direction for 2 different motions:The commanded reference trajectories are smooth and, also, include a trajectory of the CoM, i.e. the CoM is also following a trajectory relative to the wheels
From the results we can see that in the 2nd experiments the errors for the FR wheel (the one rolling a smaller distance) are much higher, reaching 7-8 % for the ode and 5-6 % for the bullet. This is in symphony with the errors I have noticed in the past in other simulations (here 3 wheels are commanded to follow a trajectory but FR wheel is, also, observed to roll while it is not supposed to). The problem exists regardless the physics engines and the durations of the commanded motion.
@alaurenzi , For the first scenario of rolling all wheels by 1 m in 4 sec using ODE, I recorded the wheels motor velocity and position (reference and real value) which you can see below.
Wheels motor velocity:
Deviation between reference and real motor velocity at peak point = 0.1 - 0.15 rad/sec for all wheel motors
Wheels motor position:
In the following, I recorded the initial and final values of reference and real motor positions, computed the difference between them (difference ref/real), converted this difference to the arc that the wheel has covered (that is distance travelled by the wheel if we assume zero slip). Also, you can see the deviation of this arc from the commanded one (ref error for the references and real error for the real motor position). The difference between the latter two is the tracking error.
Finally, it is obvious that more than 70% (in some wheels even 99 %) of the error is because of a wrong reference generation rather than tracking error. One would expect the reference motor positions to result in a reference arc equal to the commanded rolling distance.
Notice that the wheel motors are velocity controlled.
UPDATE: This issue was solved for the rolling phases where all legs roll the same distance (no support polygon reshaping). It was indeed a problem related with cartesio and the reference generation and was due to low weight of the Rolling tasks. However for rolling phases which include modification of the support polygon there exist tracking errors. In particular for a rolling phase of 1.2 m except FR foot that rolls 1.0 m we have the following:
which is again significant errors especially for the FR leg that rolls different distance. The error of the FR leg is 90 % tracking error and only 10 % error from wrong reference generation. The gains for the wheel actuator controller are
I also tested the same scenario for increased P gain and an I gain
and the results are:
The text was updated successfully, but these errors were encountered: