A simple can easily controlled by a single Arduino. But when the robot ( like the Open Source Outdoor Robot platform JECCbot mini ) and its task get more complex you need a real computer to do most of the calculations. In most cases this would be a Raspberry Pi. Using only the Raspberry Pi without an additional microcontroller is also no option because the Raspberry Pi is not very good a real time tasks like controlling the motors.
So most robots use a combination of a computer and a microcontroller like a Raspberry Pi and an Arduino board. The structure is mostly like on the following diagram:
The low level real time tasks like motor control and some sensors are connected to the Arduino. High level tasks like path planing and image detection run on the Raspberry Pi.
To get a working robot the Raspberry Pi and the Arduino have to communicate heavily.
There are three types of commands which have to be exchanged:
- Raspberry Pi to Arduino: driving commands
- regular repetitive updates from Arduino to Raspberry Pi: battery level
- Sudden events from Arduino to Raspberry Pi: collision detection, emergency switch
The most common implementation is a master-slave-system where the Raspberry Pi is the master and the Arduino is the slave. Communication is always initiated by the master. This is good for type 1 commands. For type 2 commands this is acceptable. The Raspberry Pi has to poll the Arduino regularly. Because this information requires no sudden action this is OK. Type 3 commands require sudden actions. So they are not handled very well in this system. One option is to increase the polling frequency. Then the system reacts faster but also the computing and communication load is increased.
A typical protocol for this system is Modbus ( https://en.wikipedia.org/wiki/Modbus ). There exist implementations for Raspberry Pi and Arduino.
You could also make your own protocol similar to the modbus protocol because you won't need all the functions of the modbus protocol. But then you still have the disadvantages mentioned above.
To improve the reaction on type 3 commands and keep the polling frequency low you could add an additional interrupt line. This line is activated every time a sudden event happens. Then you don't have to use your protocol to poll the status often. The disadvantage is that you have to poll the input of the trigger line with a high frequency. But this should be easier than going over USB to the Arduino. Another problem is that you need the trigger line in hardware between Arduino and Raspberry Pi. The single USB connection is now not enough.
To sum this up: I still haven't found the right setup to connect an Arduino and a Raspberry Pi on a robot to form a high performance system. All solutions have some disadvantages. When I find something new I will update this post.
If you have some better option I am very interested to get to know them!
Top Comments