Diary: make ergoCub walk in Gazebo #122
Assignees
Comments
Conda environment for development |
|
Since in the walking controller tutorial I should launch gazebo classic with: I think this is no more possible on Gazebo. Should I update the world SDF used in #103 adding the clock plugin? CC @traversaro |
By doing this, the port that gets registered is |
The issue was caused by the |
|
I'm at step 4/7 of the walking-controllers tutorial. The command: The output logs are the following: Details |
|
CC @S-Dafarra |
|
It seems that wholebodydynamics is not able to start, in particular this line: suggest that it was not able to find the model. Did you set |
In Step 1, I've done The value of |
|
To debug more easily that logic, can you run the |
|
Ahh, probably you did not installed |
Yep exactly! Do I have to install it and update some of the variables? |
|
This is the output of |
|
Probably you can just add the |
By adding that to Details |
iDynTree (the underlying library used by the wholebodydynamics module used to estimate external forces and by the walking controller) does not support loading SDF, see robotology/idyntree#481 . However, as your modifications did not changed the kinematic and dynamics parameters of the models, I think it is sufficient to use the corresponding URDF used to create the SDF. |
✅ Step 5/7I could run: receiving the |
Step 6/7When I launched the walking module with: I got the following response: |
Solved, just missed to source a setup file I use to configure needed environment variables. Now I get: |
|
The error is raised from https://github.com/robotology/walking-controllers/blob/v0.8.0/src/RobotInterface/src/Helper.cpp#L391-L401 and it is due to the fact that the |
✅ Step 6/7After #123 was merged the It produced the following logs: |
Step 7/7I then tried the last step, giving commands to the walking module with The result to the first command, Then by asking again to Then when I asked for I don't know why the While for the |
|
Here's a video of the 2024-03-18_14-34-32.mp4 |
It is possible, yes. It checks that the robot is in the desired position considering the settling time we set. See https://github.com/robotology/walking-controllers/blob/edc8984998043c98182f726e17822deb2a7b1915/src/RobotInterface/src/Helper.cpp#L980 |
Clear, thanks! BTW the method that is failing during the |
Yes it means that neither of the two local cop is acceptable, either because the normal component is too small, or because the cop is too far from the foot boundaries |
1 similar comment
This comment was marked as duplicate.
This comment was marked as duplicate.
|
I'm getting a curios behavior in my last tests: when preparing the robot it is always returning a By connecting to the robot the yarpmotorgui, I saw that the range of the elbow joints is somehow restricted to the position reached with the P.S. is it correct that the return message from the rpc command
|
|
Thank to @traversaro the issue of FTs and IMUs not communicating was solved. This was due to the fact there were some gazebo plugins missing: <plugin
filename="gz-sim-forcetorque-system"
name="gz::sim::systems::ForceTorque">
</plugin>
<plugin
filename="gz-sim-imu-system"
name="gz::sim::systems::Imu">
</plugin>Now I can read measurements via The When trying to do |
We should at least print an error if that is the case. |
Physics engine configurationshttp://sdformat.org/spec?ver=1.11&elem=physics Despite the SDF specifications has the https://gazebosim.org/docs/harmonic/comparison#physics Moreover for DART it is possible to choose what collision detector to use among (fcl, dart, ode and bullet): http://sdformat.org/spec?ver=1.11&elem=physics#dart_collision_detector Engine: DART (default)For these simulations the element
Videos: FCL cd_fcl.mp4ODE cd_ode.mp4Bullet cd_bullet.mp4 |
|
As @S-Dafarra pointed out, the weird behavior for which the |
Agree, I have to understand how to check if that plugins are available in the world. |
|
You may want to update your libode package version, during the weekend we fixed some critical bugs (see conda-forge/libode-feedstock#22 and conda-forge/libode-feedstock#23). |
I am not sure this is true. If you see https://github.com/gazebosim/gz-sim/blob/gz-sim8/tutorials/physics.md?plain=1#L100, there they report that ode is the default collision detector, and I was expecting that as that is what is tested in gz-physics tests (https://github.com/gazebosim/gz-physics/blob/7d30e47fb61fe4db9cba460717a3910df9deabee/dartsim/src/WorldFeatures_TEST.cc#L87). Can you open an issue in https://github.com/gazebosim/gz-sim to report the issue? Thanks! |
|
(By the way, can you enable visualization of contacts in this videos?) Thanks! |
is the latest libode version the 0.16.2? https://anaconda.org/conda-forge/libode |
|
Yes, but the fix is in the latest build, i.e. 14, so make sure to have installed |
Done here: gazebosim/gz-sim#2338 |
|
One of the major issues now is to guarantee that the Gazebo clock is set as Yarp clock on the Here are my attempts:
and then stops. I think this is the right path, I'm investigating the error of the WalkingModule |
This is probably a bug, ideally if the network clock is set we should avoid requiring the clock in the plugin that publish it, can you open an issue for that? |
Sorry I'm not sure to have fully understood, can you rephrase? |
This error comes from https://github.com/robotology/walking-controllers/blob/edc8984998043c98182f726e17822deb2a7b1915/src/RobotInterface/src/Helper.cpp#L391-L401 The strange thing is that when I tried logging when the gz-sim-yarp-plugins/plugins/controlboard/src/ControlBoardDriver.cpp Lines 1612 to 1629 in 6b25488 |
|
I've also made an attempt by launching the yarprobotinterface using the YARP_CLOCK variable and this is what I got: Logs |
|
Thanks to @traversaro we found out that the format of the timestamps published on the We found this by comparing the signal through YARP_CLOCK=/clock2 yarp clock /clock2 By reading this clock the format is I then updated the clock plugin to use this format and then done the walking tutorial being careful to launch both yarprobotinterface and Walking module with the YARP_CLOCK environment variable set to Here's a video of the result 🥳 2024-03-20_15-04-57.mp4The simulation is slow (sim2real ratio of 10-30 %) but that's matter for future plugins optimizations :) |
xela-95
added a commit
to xela-95/ergocub_ws
that referenced
this issue
Mar 20, 2024
|
CC @S-Dafarra @GiulioRomualdi let me know if you note something strange in the simulation or if you want me to try change some simulation settings :) |
My guess is that is not something plugin-related, but rather that the model is quite complex. Probably once we integrate the plugin in the ergoCub creo generation pipeline we can also test the minContact model. |
Why do you think that? Certainly the plugins I've written have large space for optimizations 😅 but I don't know what is their impact on the overall simulation (it will be useful to understand it BTW).
Yep that's for sure! |
|
In my opinion, some possible investigation routes could be:
|
|
I've tried to change physics engine: in addition to Dartsim, bullet and bullet-featherstone are the ones officially supported. By launching gazebo with gz sim example.world --physics-engine gz-physics-bullet-plugin --verboseGazebo crashes with the following logs: Details |
Cool, probably it make sense to check this happens without any plugin, and then report the issue in gz-sim . |
I think I can close this issue since its acceptance criteria have been met. I will open a new issue to track how the simulation changes by following these investigation routes. |
This was referenced Mar 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue will track all the technical details concerning #94.
Using walking-controllers release v0.8.0 (latest): https://github.com/robotology/walking-controllers/releases/tag/v0.8.0
The text was updated successfully, but these errors were encountered: