The robots are in a mostly functioning state with respect to their hardware, we will discuss the up and coming 4th version of the robots soon. This post is about what software we are going to produce and how it will enable people to do some very cool things (and make it possible to make interfaces for educational purposes).

Our aim is to integrate these robots with ROS , which is a huge set of libraries, communication tools, and algorithm implementations that is used heavily in the world of research robotics. It is quickly becoming the dominant interface for software intended to control robots. The cool thing about ROS is that as long as the software interfaces with a new robot are defined correctly, all the the work by the leading researchers around the world can be directly applied to your new system. Think about all of those efficient route planning algorithms, SLAM frameworks, stochastic decision making etc that your project can use with minimum work. The point is, ROS is awesome, we want to use ROS, you should want to use ROS.

So job done right? 1. Install ROS 2.???????? 3. PROFIT$$$. Unfortunately things are not that easy for us. ROS is a system generally designed for 'desktop' environments, x86 and ARM are supported, but the tiny processors on our robots are not. There is a module available called RosBridge that is for the purpose of interfacing with awkward end nodes, whether they be arduino or a webpage, and this communicates using a JSON (read: lots of text strings). Therein lies our problem, we have almost no communication bandwidth. Our IR interface can send around 2000bits per second if we push all of the timings up to and a little beyond what the data sheets recommend. To make things worse this is the only channel for all of the robots in the system, so if we have 10 robots they get only 200 bits per second. There are a few other reasons why the RosBridge direction won't work, but I think that the above is convincing enough.

So our plan is to integrate ROS one level higher in our system, on a raspberry pi that we call 'GodBot'. GodBot's job is to do all high level tasks, calculating trajectories, interfacing with other ROS enabled robots etc. All movement commands and sensor update request will be transmitted down a serial link to an embedded system that will handle the sequencing of the IR, at this time this is done by an Ardiuno. The data packets will then be sent out to the robots using a dedicated time slice to each robot. We will use a very short synchronisation symbol (4 bits) to keep things on track. Sensor requests will be handled similarly, each robot given its allocated time to transmit on the channel. Below is an outline of how the data flows around the system.

This system does require a little bit of snazzy initialisation, every part of the communication needs to know how many robots there are, and each robot needs to know what number it is. That will be a topic for a future discussion, good news though, it should be fully automatic!