/ihmc_ros/atlas/output/high_level_state_change does not get published

[Steven Gray]

/ihmc_ros/atlas/output/high_level_state_change never seems to get published, either in sim or on the real robot. On the real Atlas, I can switch high level modes, command motions in the whole body teleop mode, and switch back to walking mode. Nothing ever gets published on that topic.

[DouglasS]

@stgray I'll look in to this tomorrow morning. It may be related to issue #37; possibly an md5 checksum mismatch or something after I deleted those two fields.

[Steven Gray]

Thanks. I'm not seeing any warnings/errors about md5 mismatches like I had in issue #33

[DouglasS]

@stgray Note that this topic does not stream; it only sends out a single message when the state transition happens. I am able to get this topic on our robot.

Can you try using rqt + topic monitor and report back?

[Steven Gray]

@dljsjr I just switched modes three times and never saw anything on that topic. The mode switch is successful, though.

[DouglasS]

@stgray Thanks for double checking. I'll continue to investigate.

[Steven Gray]

Just tried this out in 0.5.1. High level state change gets published, but the value is often wrong. The message only has enums 0 and 1; why am I seeing 3 when I command joint position mode?

initial_state: 0
end_state: 1

---

initial_state: 1
end_state: 0

---

initial_state: 0
end_state: 3

---

initial_state: 3
end_state: 0

[Steven Gray]

Actually, when you fix this, could you please change it so this message is constantly published? When starting your controller, I have no way of retrieving the initial high level state - it'd be nice to have when we start with --start-position-control option.

[DouglasS]

@stgray it should be easy enough to make this topic stream.

Regarding the "3" you're seeing.

The internal number of high level states are more than just WALKING and JOINT_POSITION_CONTROL, but the additional states are not "control" states. It doesn't make sense to ask the robot to go in to one of those states, they are only used internally as "intermediate" states where parameters/gains get ramped up/down. If you were to request them explicitly, the robot would behave extremely strangely. So we didn't document them, as we feared it would lead to people attempting to send those states and making the robot freak out.

"3" corresponds to what we call "DO_NOTHING_STATE", which should only show up a.) when the robot first starts, or b.) if our automatic fall detection triggers and the robot starts the automatic pump ramp-down. If you're seeing a "3" outside of either of these two places, then we definitely have a bug.

@nmertins and I will take a look at documenting the intermediary states and maybe just putting in some engineering effort to prevent responding to anything other than "0" or "1" so that you have more visibility, as well as looking in to making the topic streamable.

[DouglasS]

@stgray If we're going to stream the topic, would you be okay with us just streaming the current state instead of the transitions so you can detect the transitions yourself?

[Steven Gray]

Yes, that would be ideal.

I was seeing the 3 in simulation because Atlas falls as soon as I move into the position control mode.

[DouglasS]

@stgray Gotcha. You should expect for us to get rid of the custom message type for high level state changes and just stream a HighLevelStatePacketMessage on the topic, just like the control topic, and probably change the name from "high_level_state_change" to "high_level_state" (shouldn't conflict with the control topic since it will still be on /output). Probably in the next day or two.