Position <-> Whole Body switching
Issue #33
resolved
What is the proper way for me to use this? It wasn't clear from the documentation. Do I need to send a JointAnglesPacketMessage before I send the HighLevelStatePacketMessage to switch modes? Or vice versa?
In JointAnglesPacketMessage, do I always need to specify every joint? Do I always need to specify torque limits as well?
Could you add a publisher so I can check if the mode transition was successful?
Comments (10)
-
-
reporter
Thanks!
-
reporter
I saw that JointAnglesPacketMessage was modified recently. Is the newest binary compiled against it? I've tried using the current and older version of that message but can't get it to connect.
[ERROR] [1430933909.174280089, 1.479999999]: Client [/ihmc_ros/atlas/controller] wants topic /ihmc_ros/atlas/control/joint_angles to have datatype/md5sum [ihmc_msgs/JointAnglesPacketMessage/bf7ea1c7acdae4c870b581c17e0ec628], but our version has [ihmc_msgs/JointAnglesPacketMessage/a525eca0901c02ebc7fa6ce4c1cf852b]. Dropping connection.
-
@stgray the .msgs were updated in error, as they are not compatible with the current Java binaries. Our robot is down for repairs all day tomorrow, and we'd like to get a new Java release out Friday. We may be able to push out a hotfix release to the Java binaries tomorrow though. You can revert that particular .msg and it should work, though.
-
reporter
The version of JointAnglesPacketMessage from 4/8 has a ROS-reported md5sum of fc0f74c73d241de495eea99853db99ec
The version of JointAnglesPacketMessage from 4/23 has a ROS-reported md5sum of a525eca0901c02ebc7fa6ce4c1cf852b
There are no other versions. Is it possible the binary was built against some local modification that was not committed? I'm happy to modify the file myself while I wait for your next release, but what should it look like? -
@stgray That's very odd that the old version doesn't work either. We'll take a look at this today and try to roll out a fix for you. Our next release will probably be tomorrow night but hopefully we can fix this today.
EDIT: To answer your question I'm not seeing that we built the release with any local modifications to the messages.
-
@stgray This has been resolved in the master branch of
ihmc_ros. Interestingly, the checksums used by ROS are seemingly not direct hashes of the .msg files… I believe that ROS must be hashing the data structures in memory, because when we finally got a file to work it did not report the checksum that ROS was asking for.Either way, you should be good to go if you pull the latest commits. Sorry about that!
-
reporter
@dljsjr Thanks! What exactly do the keep_xx_hand_in_taskspace_position flags do? If I specify true, do I not need to command arm joint angles? Will it only control a chain from utorso to the hand, or will it also try to control the back?
-
@stgray these booleans actually won't do much of anything for you and don't do much for us either. They shouldn't be exposed but they accidentally got serialized so we had to provide them to make ROS happy. Leave them false for now to avoid unexpected behavior, and in the future we will either make them useful and document them or remove them.
-
- changed status to resolved
Confirmed fixed by @stgray in commit 3e2e023
- Log in to comment
@stgray You send a HighLevelStatePacketMessage first to switch modes, and then the controller will accept JointAnglesPacketMessages. You should specify every joint in each messaged but you don't need to worry about the torque limits. Those currently aren't being used and shouldn't have been exposed in the ROS message.
A publisher that echoes the current HighLevelState is a good idea. I'll look into it.