Re: ORBit for robotics??

[Dan Kegel <dank kegel com>]

Mårten Björkman wrote:
> When we started five years ago, we used ACE. Unfortunately, it didn't
> really scale up. A complete system might include as many as 50 processes
> and the information passed between processes can be as much as complete
> video-streams. This is an extreme, of course. Such streams are typically
> few, but they do exist. When the system grew, the total compilation time
> increased tremedously and today we simply can't use ACE, at least not
> the way we used to. Another problem is what happens when you move from
> one robot to another. Some smaller robots might only have a single
> processor, while others consist of multiple Linux boxes.
> 
> So, what should we use instead? ORBit? Is it stable enough? Thread-safe?
> For some processes, like input devices, threads can be quite handy. Do
> you have any other suggestions?

I tried out ORBit 0.6 on embedded systems; in my little tests, it
performed well and had little RAM overhead.  Development of that stopped,
though, in favor of OBRit 2.  I suspect ORBit 2's overhead is something
like twice that of ORBit 1 (mainly because glib2 is a bloated pig), but
still below that of ACE.

I don't have any compile-time benchmarks for you.  Also, since
you're using the C++ binding, you may need to help finish up
the new C++ binding for Orbit 2.  Finally, I don't think it's
suitable for use in a heavily threaded environment yet.
Still, it's worth looking into.
- Dan