Review of robotics software

During my never-ending search for robotics related hard- and software, I frequently stumble on (competing) 'products' which are interesting for sharing. Looking at my previous blog entries, it looks like I'm too much staring at my belly, which is for most robotisits out there of less interest than the vast web of information on our fingertips.

So here is a new promise for 2008, getting a blog up every week about a discovery and, my completely irrelevant opinion about it. If you feel you can do better, log in and create a blog entry yourself. That's certainly easier than getting a ball-catching, camera-assisted dual 8DOF back-drivable robot arm up and running with Orocos. Your choice.

If you directly skipped to this paragraph, you're clearly the 'quick learner' type that figured out most blogs get interesting around the links. I hit this [Windows for devices article|http://www.windowsfordevices.com/articles/AT7322940023.html] which presents a nice table comparing various robotics platforms. Yes, we're in there too. Please note the commerical/open source software ratio and do something about it. Also note the single platform that does not officially support Windows. Each of these projects is an interesting starting point to learn more about the current state of robotics platforms. So what do we learn after following some links ? That [URBI|http://gostai.com/] has a promising scripting language, but does not offer much structure for building larger than simple applications. That [Microsoft Robotics Studio|http://msdn2.microsoft.com/en-us/robotics/default.aspx] has an appealing visual programming environment, but also lacks structure for building larger applications.

What do I mean with providing 'structure' ? It's not dividing applications in submodules, we all do that, don't we ? It's allowing a user/programmer to specify composite, parallel and hierarchical behaviors __and__ the transition between those behaviors. Enter state charts: If the [UML|http://www.uml.org] folks got one thing right in their overly complex meta-model, it was adopting this specification. This is not the place to teach you about state charts. Read this [Introduction to UML 2 State Machine Diagrams| http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm] for a good introduction and this [Embedded.com article about UML state charts| http://www.embedded.com/columns/beginerscorner/13900141?_requestid=75668] for a more complex use case. Now learn what true visual programming of robots should look like. Wanna help me ?

See you next week !

Concerning URBI

Hello,

Did you have a look at http://www.gostai.com/studio.html and
http://www.gostai.com/video/URBIStudio.mpg ?
This tool generates the states code. Is it what you are looking for?

--
gnibu

Nice demo!

URBI is worth a blog entry of its own. If I had an AIBO, I'd be using URBI to play with it (now send money please :-). This URBI studio product is not available yet, but it looks like it accomplishes at least half of what I hoped for, which is a lot. In my working environments, behaviours are often more complex than demonstrated and especially the transitions between behaviours must be controlled and specified precisely, just like UML state machines allow. I'm not sure URBI studio will feature this complexity yet, on the other hand, I believe it will be a great inspiration for future robot programming (which no user really wants to do...)