Is QNX 6 the best OS for autonomous vehicles?

Several of our team members spent some time looking into the various operating systems for autonomous vehicles (cars that drive themselves). We narrowed it down to three candidates, QNX 6, Linux, and VxWorks. Flavors of Linux support mostly soft realtime, and VxWorks is best for small footprint processors.

It seems that in the vehicle environment, QNX 6 is the operating system of choice. Interestingly, we found that several DARPA Grand Challenge participants are using QNX, as well as important research projects at Carnegie Mellon University.

We will be using several SBS CompactPCI boards communicating across the backplane, in a rugged enclosure.

Any tips on how to best take advantage of the unique QNX 6 features are appreciated. Right now I see the most interesting aspect as how to distribute the flood of various messages being passed amongst the processing modules from all of the sensors and feedback devices.

Dan

p.s. Our project web page is at http://www.autonvs.com. We are welcoming new members in the QNX 6 development aspects, taking place in the Southern California region.

Doing message passing (networking) over PCI backplane is usually not a very good idea, because unlike networking all the work is handle by the CPU.

As for tips, well I only have one, read the whole documentation, twice ;-)

Hi Dan,

Congratulations on your selection.

If licensing costs are not a hinderance, QNX6 is definitely a winner for the kind of hard realtime tasks you’re getting into.

However, the successfully use QNX6 is another challenge. I’d advice you against using all the nifty features early in your venture because its easy to get lost in the wonderful land and end up with an over-engineered application too late of the deadline… especially if you’re a newbie to QNX land.

For the start just concentrate on the bare-bone features you need for the prototype. Then when you’re more comfortable, go on to message based architecture. Keep the soft realtime parts in separate threads and hard realtime separate. Build separate modules as separate execution threads and communicate between them using the standard IPC mechanisms and then move on using async messages for soft<->hard RT components and sync messages for hard<->hard RT components. Keep it short and simple and QNX will do wonders for you.

Good luck