Creating Backbone Software for your Robotics Project

This write-up will show you (very generally) how I went about creating a software backbone and give you a base to start your own software backbone project.

Before we dive into software we need to look at some background information to help give us scope.

Find a Hardware Platform

First, you need a hardware platform.  I chose to use TI’s BeagleBoard ( http://beagleboard.org/ ) as the main system computer for TurboFin.  This board is very powerful, for an embedded system, and runs Linux.  Linux is important here because it allows you to design software just like you would on your PC, using GCC to compile no less.  It also means that you don’t have to do the dirty work with memory management, Ethernet stacks, etc.  All this is done for you just like the PC you’re reading this on now.  One last major advantage:  there is a HUGE Linux support base on the Internet.  Have a problem?  The solution will very likely be the same as on a desktop machine.  All this means you can be up and running with software in no time at all.

It is important to remember that although the BeagleBoard is relatively fast (750MHz for the version I’m using), it is still very slow compared to other systems running a full Linux distribution.  For this reason we want to use a very lightweight distribution.  I would strongly recommend Xubuntu (a Debian derivative using XFCE desktop environment).  Even with a lightweight operating system, we need to keep our programs as light as possible to avoid creating processor lag (after all we want this to be as real-time as possible).  Yes, there are real-time distributions of Linux, but from my personal experience, it’s easier to get up and running with a distribution like Xubuntu, your mileage may vary.

Files in RAM

If you wind up using Linux, it is very easy to create a virtual file system in memory.  Once this is done, you can read/write to files in this filesystem just as you would a file located on an actual hard drive.  The main advantage here is speed.  Also, if your operating system lies on a flash drive (SD card for BeagleBoard), you will not wear out the card as fast, as you won’t be writing to the flash memory as often.  For information on setting this up, visit:

http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/

Choosing a Language

Second, you’ll need to decide on a language.  I prefer coding in C when writing robotics applications.  The reason is simple: portability.  Almost every mainstream microprocessor has a cross-compiler that accepts C.  This is nice, as you can code, test, and debug your programs’ logic on your PC without having to upload it to your device every time (obviously not the case if you’re interfacing with on-chip I/O).  Also, as long as you keep your applications void of platform-specific API’s, you can compile and run your program on just about any computer with any operating system.

Down to Business

Okay, now that you have a good idea of your tools, you need to come up with a list of specifications you want.

We want the following (well, I do, anyways):

• Written in C
• Independent of platform specific API’s (when at all possible)
• Designed to be very lightweight and fast
  
  • Use little CPU power
  • Use mostly RAM for files – this prevents thousands of slow read/writes to the memory card (used as the “hard drive” on the BeagleBoard)
• Provide remotely and locally accessible data using the exact same connection procedures (i.e. Linux sockets)
  
  • This will allow manual control of the robot, but also provide for the future capability of an autonomous program to control the vehicle
• Data we would like to see:
  
  • Roll/Pitch/Yaw
  • Pressure (determining depth)
  • Live video feed (hard to steer from the surface otherwise)
  • Depth finder (acoustic transducer actually) – for finding distance to sea floor
  • Water sensor (are we leaking?)
• Hardware we would like to control:
  
  • Motors and other actuators
  • Accessories (lights, claws, etc.)

Sockets

I highly recommend you familiarize yourself with Linux sockets before proceeding:

http://www.linuxhowtos.org/C_C++/socket.htm

Linux Sockets are the means by which multiple processes can communicate with each other both locally (on the same machine) and remotely (on any computer connected by Ethernet).  In the diagram below, the “hub” server uses Linux sockets to communicate to other programs.  These other programs may include a manual controller, a data viewer (by which the users can see the current dept, speed, etc.), and/or any other program that uses information that needs to be shared.

Upper Level Data Flow 

Figure 1

As you can see by the above flow chart, the central piece of software is the hub server.  This program listens for incoming connections, validates the command, and acts accordingly.  Next along the data path is the “Temporary File”.  These are files stored in a ram disk, as discussed earlier.  They are just ordinary files that hold information relevant to the robot.  For instance the file related to current depth may just be a text file containing a single number.  These files are also read and written to by individual controllers.  These controllers interface with external hardware to either send information or gather data.  For example, the motor controller process takes values from the “motor controller temporary file” and sends data (via serial in my case) to an external device that in turn sets the motors to a specific speed.  In a similar manner, the telemetry controller reads serial data from external sensors and writes these values to corresponding temporary files.

As an example, let’s suppose we have a program (client) running on a monitoring computer connected to the robot via Ethernet.  This client’s only task is to display the vehicles current depth.  The client would first request a connection to the hub program (host) running on the robot.  The hub server presumably allows the connection, and now the two are linked.  The client then sends a request for depth data (the protocol for this is completely up to you).  The host then accesses the file stored in RAM that contains the depth data, reads the file, closes the file, and sends the requested information back to the client.

You may be asking yourself, “Why would I go through all this trouble when this can be done using an existing database application such as MySQL?”  This is a very legitimate question with (what I believe to be) an acceptable answer:

Speed and Complexity:  MySQL is relatively slow when you’re trying to update many fields at kilohertz frequency because it uses a hard drive (or even worse, in my case, a flash drive).  You can modify MySQL to run in RAM.  However, even if you do that, you’re going to need to interface with the MySQL database.  Meaning, you may have to manually port MySQL (or at least the client portion) to any device that needs to access the database (not fun).  This isn’t the case for the BeagleBoard, but worth noting nevertheless.  In the case that MySQL is writing to a flash drive, you will burn through the card MUCH faster than had it been writing to RAM.

Why I Chose This System

This system works VERY well for my needs.  I am able to write, compile, and run code on a remote machine, and have it act as if it were running on the robot.  An example of this is the depth controller (the process that actually decides the depth, not the process that relays this information to the external hardware which actually reacts).  I am able to tune the values of the controller on land while the robot is in the water.  When I am happy with the results, I can upload the code using SCP and compile it remotely using SSH and GCC to have the code running on the BeagleBoard.  This brings up another advantage to this system.  Supposing at some point in the future I find the BeagleBoard is too heavily taxed, I can reduce the burden on the main board by adding another BeagleBoard to the robot (connected to the first by an Ethernet switch) and run programs on the second board without any code modifications (save IP address changes).

Summary

So in closing, I found that using Linux sockets to create a hub-style data backbone has worked very well.  It is both fast and processor friendly (does not tax the processor much at all), and allows programs to run either on the local machine (robot) or remotely without any code modification (save IP address changes).