update on 25-08-2013

Communication Flow

Board-to-board communication and general work-flow concepts

A similar thinking can be done for board-to-board communication. In this distributed computing environment the communication is a very important argument. At first it seems that a unique bus is the best way to connect all the boards, but a protocol that fits all the needs risks to be too heavy for a time-critical task and to weak for other tasks and, furthermore, this situation would require a multi-master strategy that would cause an high level of unpredictability on response time.

As can be seen in the schematic, the tasks have been well separated in "black-boxes", where a processor can be a master for its own task toward other processors of the same sub-system and a slave toward an upper level processor. The master dsNav motor controller can execute a 1KHz PID cycle while keeping the slave board synchronized at a fixed and precise 100Hz rate. The dsNav chain can trust on a costant 40Hz rate of information from IMU, even if the HLS can hardly maintain a 10Hz rate update. On the other side, this 10Hz rate is more than enough as a GUI and video refresh rate.

To communicate outwards a WiFi adapter is connected via USB bus to the ARIA G25 board. This creates a link to use the GUI and the web-cam video streaming with any standard web browser.

The High Level Supervisor (HLS) is the hub for all the communications and high level navigation strategies. It collects all the navigation data from the lower levels subsystems and decides the behavior. The robot is autonomous, but some level of human interaction for both telemetry or manual driving could be useful. The HLS acts also as a web server to publish the JavaScript client, a GUI compatible with any HTML5 web browser. The node.js server running on HLS allows a bidirectional communication through a web socket for a real time client-server communication. Another node.js module creates the gateway between the web socket and serial communication to exchange data even from the lowest level board to the web GUI.

Going down through the communication chain, there is the IMU board. It is the hub for all the hardware involved in navigation. It collects GPS, magnetometer, gyro and accelerometer data. Using sensors fusion with DCM it returns the orientation value to the master dsNav board, to compute the correct dead-reckoning, and returns the current position to the High Level Supervisor.

Here a detailed description of the communications and boards involved with navigation.

Another important part in the communication chain, is the Low Level Supervisor. It takes care of all the power supplies and collects data from the obstacles detector. It also allows hard or soft switch-off for the entire system. The light intensity of the front headlights is controlled too by this multi-purpose, low level board with a couple of Arduino PWM peripherals.

To allow a quick view to some critical parameters (batteries levels, internal temperatures and error codes), even if the remote GUI is not operative, a display is directly connected to the LLS via I2C protocol.
On the same I2C bus a sonar range finder is connected to LLS to detect the obstacles encountered by the rover. All the lower level tasks are executed inside the sonar MCU to return clean measures to the LLS.

In a complex system, as an autonomous robot is, there are many tasks to be executed. Someone are time critical, some others require the management of large amount of data or sophisticated mathematical operations; one requires a simple and fast communication protocol, other requires a full stack of standard and reliable protocol like TCP/IP. There isn't a unique solution for everything. The best solution is to distribute the tasks among different, specialized processors that fit at the best those specific purposes.

A dedicated dsPIC board, with specialized peripherals, without Operating System, running a full optimized C program, is the best to control a 1ms cycle PID. A 32 bit, ARM based, 256 Mb of RAM computer with a Linux OS is much more better to run a web server with standard libraries. Programing an Arduino board is fast and easy if you need to manage a lot of analog and digital I/Os in a non-time-critical way.

In addition to the USB bus for massive data exchange (video streaming and web services), serial and I2C communications are involved. All the serial communications use my light protocol that allows a fast and deterministic exchange of commands and little packets of data for telemetry and similar. The I2C comm uses the classic protocol applied to the I2C EEPROM: a first write points to a specific register and consecutive readings/writings automatically increment the pointer.

The safety is a very important issue for an autonomous vehicle, both for its integrity and for the human health. A special attention has been applied on every board software to prevent "blind travel". On each board the internal watchdog system or something similar, has been used to keep the board in a safe state if the communication with other boards is lost for any reason. The startup condition for all the boards is designed to have motors halted until a higher level order arrives.

The entire system will be described below in a hierarchical, top-down fashion.

Every time a command is serially sent from HLS to IMU or to LLS a timer is started. If the answer do not come back within a given timeout a counter is incremented. After a given number of subsequent failures the HLS decides it can no more rely on the position in space of the rover and/or of the obstacles. This starts the shutdown procedure that "poweroff" the LLS and tries to switch off the power supplies, in order to put everything in the maximum safety state.

When the dsNav boards program starts-up it has not yet been defined slave nor master. At the moment a particular command arrives from the IMU the front board becomes master and send a command to the back dsNav to define it as a slave. Until these commands don't arrive the watchdog timer resets the boards every timeout keeping the motors in stop position. The IMU board too has a watchdog timer that resets it if no commands come from HLS on time. In any moment whatever communication channel faults for a time longer than given timeout, everything is reset in the aforementioned way to stop the rover.

The LLS receives directly the switch-on and switch-off (hard or soft) commands. It performs an health check-out at startup before enabling other boards. The same check is repeated periodically. If some power supply faults or there is no communication with HLS and/or QuadSonar for a long time, the LLS tries at first to gracefully switch-off the HLS. If it can't be done the power is get off abruptly: it's better to have some possible corrupted data on HLS file system rather than some physical damages!