No Sim Footstep Feedback

[Dave Kotfis]

The simulator is not publishing anything on /atlas/outputs/ihmc_msgs/FootstepStatusMessage, which makes the boxStep.py script hang after marching in place.

This issue is not present on the hardware version.

[Stefan Kohlbrecher]

Also noticed this, but I somehow managed to run the whole boxStep demo at least once in simulation. Unfortunately, I have no idea what I did to make it work (played around with publishing different things before running boxStep).

[DouglasS]

@dkotfis @Stefan_Kohlbrecher Thanks for the bug report. Sorry nobody responded to this earlier, somehow our email notifications got all out of whack. We'll look at this ASAP.

[Stefan Kohlbrecher]

Any news on this? We're looking into integrating our footstep planning system now and it would be good to have the feedback.

[DouglasS]

@Stefan_Kohlbrecher We can't reproduce this reliably yet. But we have some ideas as to what may be causing it and hope to have it resolved very soon.

[Stefan Kohlbrecher]

Update: We also can't reproduce reliably (it does work in about ~25% of cases). When it doesn't work this error is written to terminal at startup:

#!

Exception in thread "Streaming Data Producer" java.lang.RuntimeException: RosTopicPublisher is not registered with RosMainNode
    at us.ihmc.utilities.ros.publisher.RosTopicPublisher.checkInitialized(RosTopicPublisher.java:49)
    at us.ihmc.utilities.ros.publisher.RosTopicPublisher.publish(RosTopicPublisher.java:35)
    at us.ihmc.utilities.ros.publisher.IHMCPacketToMsgPublisher.consumeObject(IHMCPacketToMsgPublisher.java:26)
    at us.ihmc.utilities.net.LocalObjectCommunicator.consumeObject(LocalObjectCommunicator.java:34)
    at us.ihmc.utilities.net.LocalObjectCommunicator.consumeObject(LocalObjectCommunicator.java:15)
    at us.ihmc.utilities.net.ObjectProducer.sendObject(ObjectProducer.java:18)
    at us.ihmc.utilities.io.streamingData.NonBlockingStreamingDataProducer.notifyConsumers(NonBlockingStreamingDataProducer.java:15)
    at us.ihmc.utilities.io.streamingData.NonBlockingStreamingDataProducer$1.run(NonBlockingStreamingDataProducer.java:35)
    at java.lang.Thread.run(Thread.java:745)

[DouglasS]

@Stefan_Kohlbrecher Thanks for the stack trace. We're taking a look and should know more soon.

[DouglasS]

@Stefan_Kohlbrecher my current suspicion is this is caused by an in-process native ROS component taking a very long time to shut down when the Java component shuts down; the result is that if the sim is closed and then re-launched again in succession there is a chance that the ROSJava portion won't be able to connect to the ROS Master. ROSJava fails silently until we attempt to broadcast topic info and publish messages on the node at which point you'll see this message. It also explains why the topics are missing.

This is definitely something we can and should fix on our end. The short-term workaround is to run "ps aux | grep java" after everything else is shutdown and sending a "kill -9" to any leftover IHMC java processes. This orphan Java process is the parent of the dangling native ROS component and so killing it should tear down the underlying native stuff.

[Martin Oehler]

I made a few tests and I don't think this is the issue. After closing the simulation, "ps aux | grep java" didn't show any left-over processes. Still the problem persists, that the posted exception is thrown.

[DouglasS]

@Martin_Oehler Are you running with the build currently up on BitBucket, or the pre-release software we gave to Stefan at South Carolina?

[Stefan Kohlbrecher]

Martin is running the old stuff, but I can provide the new one to him (Unless you guys are just about ready to do an official updated release :D ).

[DouglasS]

@Martin_Oehler @Stefan_Kohlbrecher I would suggest using the pre-release software we gave you in South Carolina, we should be pushing a working build to BitBucket in the next day or so. We have run extensive testing in Sim and on the real robot, and the only time that the topics aren't correctly published is when the ROSJava node isn't wired up. This ROSJava failure occurs either if there is a dangling Java process or if the IP's aren't set up correctly. Note that ROSJava doesn't inherit its ROS info from the shell environment, so we have to pass that configuration in to ROSJava from our code. The config file containing the IP info is different between the two releases you have access to, but you are probably more familiar with the config files we used in South Carolina so I would go that route.

[DouglasS]

Fixed in 0.3.1-alpha.