PDA

View Full Version : Robot OS



Ironman
02-14-2009, 01:02 PM
Hey Guys,

I was wondering if anyone has run a robot os, like orca, player, carmen, or ROS. My team is currently working on creating a software framework/AI/ device drivers for ubuntu. I feel that if we could get a framework that's already done it would be extremely helpful.

Any suggestions would be greatly appreciated.

elios
02-14-2009, 01:58 PM
good point!!
i know that 4mem8 is using a pico ITX computer on his J5 just running a serial program in C. i think thats what most people are doing, actually.

Adrenalynn
02-14-2009, 02:06 PM
I've run Player/Stage and Carmen.

If your hardware _exactly_ matches their supported hardware, they can be worthwhile.

Hardware is so vast and varied it's hard to really get a leg up. And tasks are so specific it's hard to steal a lot of code that will really send you anyplace. I think it depends a lot on what you're looking to do - duplicate someone elses experiments or head off in a new direction of exploration?

>> i think thats what most people are doing, actually.

I doubt it. The number of C programmers here could probably be counted on one or two hands. I doubt 4Mem has ever compiled a C program, let alone written one. And what's a "serial program"?

Nammo
02-14-2009, 02:26 PM
I was wondering if anyone has run a robot os, like orca, player, carmen, or ROS. My team is currently working on creating a software framework/AI/ device drivers for ubuntu. I feel that if we could get a framework that's already done it would be extremely helpful.


If you are already very comfortable working with large scale software in C and Linux, Player or ROS is the way to go.

My humanoid robot Snappy uses Player for motion control and kinematics calculations. Player was definitely easier for me to fit and extend than Orca, Carmen, or Microsoft Robotics Studio, since it has more of an open source/Unixy design philosophy.

ROS is being developed by the same people that created Player. Brian Gerkey (key developer of both Player and ROS), has said that ROS is the better starting point of the two, since the project has learned from Player's mistakes and is now where the bulk of new development is happening. On the downside, ROS is not as mature as Player so you should be prepared to get arms deep in the code.

Just to echo Adrenalynn, these are not plug-and-play packages for hobbyists. But they are powerful. If you are a C and Linux guru you'll find ROS and Player fairly easy to integrate into your robot. But once you're done, you might not have much. You can leverage localization if you have a laser scanner, or some of the new visual SLAM stuff in ROS if you have an 8 way Core i7.

But this is probably overkill for 99.9% of the projects we build here!

- Nathan

Adrenalynn
02-14-2009, 03:07 PM
+Rep - great experienced info!

Ironman
02-14-2009, 11:56 PM
Thanks for all the good info.

I'm still having a hard time understanding what exactly the robot operating system would do, compared to say like ubuntu.

we've got like a 12 man software team, i'm just doing some preliminary research for them to try and save them some time.

Ironman
02-14-2009, 11:58 PM
i'm also one of your C programmers :)

Nammo
02-16-2009, 12:51 AM
Thanks for all the good info.

I'm still having a hard time understanding what exactly the robot operating system would do


Like all good OSes, ROSes have four main goals:

1) Supply some of the pieces you will inevitably reinvent if you develop your own robot from scratch.
2) Encourage you to use a well-thought-out framework for your code instead of repeating all those inevitable mis-steps and rewrites in a home-made framework.
3) Make it easy to port your robot "application" to new types of hardware.
4) Help you leverage the economies of scale of a common platform: That is, you can hire people who have worked with the platform before, find well-written books and training courses that cover it, etc.

For #1, Player/Stage supplies sophisticated debugging mechanisms including a couple of fantastic simulators (more on this later), a host of "basic algorithms" you will need for a mobile robot (SLAM, path planning, motion control), and drivers for common hardware you will use during development (off the shelf sensors, cameras, laser scanners, motor controllers, etc).

For #2, ROS is probably even better than Player. Although ROS includes most of the same algorithms and drivers you'd find in Player, they have improved and simplified the framework based on what was learned in Player. In any good framework, there are a lot of non-obvious details, and you may not understand why they are important until you misimplement them yourself. This is a way to save the trouble.

For #3, this may sound unimportant, but it is likely that during development you will change motor drivers, sensors, microcontrollers, or even details like the dimensions of the robot. Unless you work inside a properly constructed framework (see #2), dependencies could creep throughout your code that make these adjustments very difficult to handle. Although you may not think of portability as an important part of robotics, it is especially useful in simulation, where parts (or all) of the robot code may run on PCs instead of microcontrollers.

For #4, there are great public Wikis available on both ROS and Player/Stage. Player in particular has a vibrant community with people willing to answer newbie questions on forums. There are even books and tutorials available.



compared to say like ubuntu.


ROS and Player don't compare as well to Ubuntu as they do to, say, the Linux kernel and the GNU toolchain. With these tools, you can build almost anything, but alone you just get a blinking cursor and some text. You are still expected to "write the application" for your robot.

If you want something more like Ubuntu, which provides finished applications, you should look into tools like URBI or possibly Microsoft Robotics Studio. (URBI is partially based on Player/Stage, much like Ubuntu is based on GNU/Linux.) You can buy an off-the-shelf robot and run off-the-shelf samples and get some cool behavior right away. They may not be a helpful starting point if you are going to develop something vastly different than the samples.



we've got like a 12 man software team, i'm just doing some preliminary research for them to try and save them some time.It sounds like you are taking on a very ambitious project. In that case, ROSes are worth more than a second look.

Let me tell you from (painful) experience:

I worked on a fairly ambitious mobile robot with a (software) team of 5, and so I now have a huge appreciation for the four points I listed above. When we started, there was no appreciation at all.

We didn't even use an embedded OS, much less an ROS. Instead we just started writing code that bangs the hardware. This will get you pretty far, but then you start to really want a way to run code on the PC in a simulated environment. It saves time, helps QA, allows unit testing, and most importantly, makes it possible to debug and visualize the state inside the robot in a way that just isn't possible by watching your device bumbling around the floor.

Another mistake we made was to just immediately start designing our own platform from scratch. Early on we didn't know exactly which sensors and actuators we needed. We would've been better off buying off-the-shelf sensors at high cost than spending months of valuable time developing our own sensors for production -- only to learn that we didn't need them or they didn't work.

So if you think you won't need drivers for off-the-shelf components, you're probably doing it wrong.

Since then, we have hastily reinvented all of the core functionality in Player/Stage, including our own Player-like component protocols and a simulator we use for QA and development. Along the way we discovered why Player works the way it does, and puts such an emphasis on simulation even at the expense of other (seemingly nice) features.

Without a simulator in your project you will eventually hit a wall. And retrofitting it in later is very hard.

On the one hand, our tools are perfectly tuned to our environment and needs. On the other hand, when we bring new people on the team, there is no documentation and a high learning curve. With something like Player, we might be able to set somebody down with a 3rd party book and Wiki and expect them to be productive much sooner.

- Nammo

Ironman
02-16-2009, 11:14 PM
wow, like no joke, most awesome post I've ever read.

Thanks. I will definitely be sharing this info.

droidcommander
02-17-2009, 03:52 PM
Adrenalynn,
Isn't this right along lines with the TRS Project? How does that fit into this equation? I know that there are a greater number of us looking at using more full blown PC's for our robotic projects instead of/or in order to complement a good microcontroller. Can you give us any information on how the TRS differs from Player/Stage, ROS, orca, carmen, or the architecture that ironman has presented with this post?

Thanks
DroidCommander