Which IPC choose in mobile robot?
- Message-passing
- Message queues
Hello,
I’m going to write a piece of embedded system and having a dilemma with choosing appropriate IPC method.
My software will contain of several drivers of mobile robot’s sensors, motors etc. So I have choosen Resource Managers with Message-passing mechanism. But I considered that Message-passing mechanism always needs send-reply pair. In effect this will stop user program for some time and will make processes concurrency unavailable (reading data from sonar and travelling using motor in the same time). This can be possibly repaired by using many threads in user program.
But there is another method named MEssage queues. This method is possibly much slower then Message-passing but none of messages needs reply (and can be queued) so processes can concurrent easily.
I do not really need extreme speed of passing small amounts of data between processes but Resource Manager solution is very helpful. In QNX Resource Manager is almost one piece with Message-passing mechanism. Is it really good solution to make Resource Manager with Message queues? Which way is the best? Did anyone have such dilemma? It is very important for me to know it before bigger parts of my software will be created.
If I am making any mistakes in my way of thinking please let me know because I am newbee in QNX environment. If any other informations will be neccessary I can easily write them down here.
Thanks a lot for any help
Dobromir
Your first thought for architecture is good.
Newbies to QNX often have a problem with this apparent lack of asynchronous capability in native messaging. I say “apparent” because, there is an asynchronous mechanism that is part of native message passing.
In your resource managers you can implement the IO_NOTIFY capability. This allows your RMs clients to specify what events they want to be asynchronously notified of, and all actual data transfers between the client and RM remain Send/Receive.
For instance (simple/contrived), let’s say that you have a client that is responsible applying the brakes when the sonar indicates an obstacle less than 1 meter ahead on the trajectory. This client would send a message to the sonar RM and request to be notified when an object is detected less than 1 meter. The sonar message would contain distance and direction. The client would then simply wakeup everytime it gets a notification from the sonar RM, and read the message, it would then send to the navigation RM to determine current direction, and if the object was determined to be in the trajectory, it would then send to the braking RM. The communication to the navigation and braking RM requires no (in fact shouldn’t have) asynchrony, since the query operation against the navigation RM should be “non-blocking” (i.e. consume no appreciable time) and the stop operation against the brake RM needs to be confirmed as successful before any further action should be taken.
Since the sonar RM notifies the client with a MsgDeliverEvent (which is non-blocking), it can continue to provide sonar updates to other clients, while the “collision avoidance” client is checking with the navigation RM for trajectory intersection. Thus you have true asynchronous processing where (and exactly where) you need it. Utilizing an architecture such as message queues spreads asynchronous behavior over everything, and you’ll find that you spend much of your time trying to synchronize the 75%-90% of your application that demands synchronous behavior.
Note too that you can associate a priority the sigevent that the server will ‘ping’ you with, thus allowing you to make that sonar notification more or less important in relation to other messages. You lose priority information when you use msg queues.
Thank You very much for answers.
I really didn’t know about making QNX native messaging asynchronous. Many things look easier now. I gonig to try message-passing idea. That’s for sure. I’ve understood some new things.
Thanks for examples and extra ideas.