Ask Your Question

can smach co-exist with a pre-existing mainloop?

asked 2011-02-26 21:04:21 -0500

AndrewStraw gravatar image

I'm evaluating smach for use in a ROS node I'm developing. The purpose of this node is to draw graphics using the Panda3D library. This display server will have different states (e.g. blit 2D images sent as ROS messages to the screen, draw 3D graphics using realtime tracking data sent as ROS messages). So, at a high level, it seems natural to use smach to manage such a state machine. However, the strongly recommended way of using Panda3D (like all GUI frameworks I know) is to setup event-driven callbacks and then call Panda's method, which never returns (until the app is done). I didn't find any documentation or examples referring to use of smach within such an external event loop.

My question is: is it possible to use smach in this kind of environment? If so, how? What are the issues to consider?

All the smach examples I've seen leave the Python script in charge of control flow and the StateMachine.execute() method itself seems to take the role of a main loop. If I relegate overall control to Panda's mainloop, I guess that the smach state would have to be maintained in callbacks that get registered with the Panda event handler. There are various callbacks that could be used in Panda, including an "on every frame" callback.

Briefly looking into the code for StateMachine.execute(), it seems that smach itself assumes the role of the main event loop. So, I guess my best option to make smach co-exist with another main loop is to put the constituent pieces of execute() into custom functions. Then StateMachine._update_once() could be called as frequently as possible from the Panda event loop. I guess something like this approach may be my only option if I want to keep Panda's main loop. I also guess that this approach isn't exactly the supported use case of smach.

Alternatively, it is possible, but discouraged by the Panda developers, to run one's own mainloop as described at . So, I may have to use that approach as a last resort and let smach run the program's mainloop. Nevertheless, I'd prefer to use Panda in the style that the Panda developers promote. This would also facilitate using smach within other GUI programs that also assume control of the mainloop.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2011-02-28 10:26:50 -0500

Wim gravatar image

updated 2011-02-28 10:27:22 -0500

I think your assessment is correct, Smach assumes the role of the main loop itself, and is kind of awkward to use asynchronously. The Smach roadmap has some pointers to initial experiments with asynchronous Smach. There is even a">repository containing an implementation and example usage of asynchronous Smach.

edit flag offensive delete link more

answered 2011-02-28 11:56:41 -0500

It seems like you can put Panda's in a separate thread. Might be a bit messy though, I imagine lots of semaphores in the callbacks.

edit flag offensive delete link more


BTW I usually put GLUT's main loop in another thread, which is where I am coming from with this idea.
veltrop gravatar image veltrop  ( 2011-02-28 11:57:48 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-02-26 21:04:21 -0500

Seen: 749 times

Last updated: Feb 28 '11