Complete ROAMR setup

This is my robot in it's complete setup, of course I'll work on actually fixing everything in place properly, but all the hardware and such is there. I haven't been able to reliably send the Kinect data over wifi using ROS, so unfortunately the mapping and navigation algorithm isn't implemented yet, however I am controlling the robot from my laptop remotely over ROS. There are nodes running on each of the computers:

• The controlling laptop publishes steering data (this is what you see running in the terminal at the beginning)
• The robot in turn listens to this steering topic, and writes the appropriate signal to the Arduino onboard, which then controls the actual motors.
• The robot also publishes the Kinect data over ROS topics, however they don't seem to get through (my network stats show that the outgoing data constantly peaks at around 230KiB/s, but no actual images get displayed on the host computer) I believe this is because of the poor wifi card built into the laptop on to of the robot, I'm currently working on getting this to work
• The controlling laptop listens in to this data, and will, once it's working, run it through the ROS RGB-D SLAM algorithm.

Eventually, I will try to implement odometry for the robot so I can use the ROS gmapping algorithm instead, which produces 2D maps of the robots environment and better allows for navigation. i also expect the resulting maps will be much smaller in filesize - the RGB-D SLAM produced maps are often several GB large.

Here's the video:

ROAMR update

Albeit a small one. Here's two recent videos of the robot, still remote controlled at this stage, as I'm working on getting Kinect data sent via ROS, but the high bandwidth seems to be causing problems. However, I've already got a setup where I can mount my laptop to the robot, connect the Arduino via USB and steer the whole thing from a third computer over the Wifi network using ROS.





I'm using a 12V lead-acid battery and a L298 motor driver. My motors only take 6V, so the PWM pins are running at a maximum of 50%. I'll upload the code soon.

An update

Okay, so I've been pretty busy/on vacation lately and haven't been working on ROAMR very much, but I have made some progress which I'll talk about in a bit. First of all though, I wanted to share that I've finally setteld on where I'll be studying this fall. A while ago I had gotten accepted into Jacobs University Bremen, and I was pretty excited about it. However, they didn't offer me any scholarships so I decided not to take the offer. I was then considering KIT (Karlsruhe Institute of Technology), and was still waiting for a decision from the Technical University of Munich. I settled on TUM after getting the decision the night before my birthday. KIT and TUM are ranked pretty similarly by most sources (KIT tends to do a bit better, to be fair), but I decided on TUM because Munich is simply a much more exciting place to live, and I like their campus better. Also, they have slides in the Computer Science and Mathematics building. In addition, they appear to serve Pretzels and free beer during freshman orientation.

I believe if those slides were in the faculty for Physics, they would probably just lead right into each other.

I spent the last few days in Munich looking for an apartment (or a room, rather), and I finally found a nice one close to the campus.
I can't wait to move in, I should be getting there sometime in September.

So, now for the ROAMR project. I decided that for this sort of robot, it would be useful to implement a SLAM algorithm for mapping of the environment and autonomous navigation of the robot. The obvious sensor choice to be was a Kinect sensor, as it is fairly cheap and allows for full RGB-D mapping of the robots environment.
The downside of using a Kinect sensor is of course the fact that the robot will now become significantly bigger, and heavier. The Kinect feeds a very large amount of data, certainly too much for an Arduino to handle (not that the drivers exist anyway), so I find myself forced to mount a laptop (or at least a netbook) onto the robot, as well as a 12V battery to power the Kinect (which also dissipates energy at about 12W).
ROAMR is meant to be an experimental and (self-)educational project, I'm not looking to implement anything revolutionary or something that will have enormous potential for practical application, it's really just for fun. For this reason, I don't mind that adding a Kinect and Laptop will make it rather big and heavy in comparison to what it started out as. If someone (or me, later) was to build such a robot with similar hardware but needs it to be smaller, something like a Beagleboard could be used to transfer the Kinect data remotely through, for instance, a ROS topic. I am also considering a Raspberry Pi, but I will have to wait and see if anyone can get the Kinect drivers to work on it. The calculations and SLAM would then be done from another machine, the ROS Master node if you will, which effectively acts as the brain for the robot. The problem one runs into with this, however, is again the large amount of ata produced by the Kinect - not all (if any, I have not gotten it to work yet) WLAN connections will be able to provide the bandwidth necessary, and as far as i know ROS stops publishing to topics once the bandwidth is too high. So perhaps some kind of pre-processing or compression would need to be done onboard the robot.
In any case, here is what I plan to implement or look into for ROAMR:

• Since I have two Laptops at my disposal (one significantly more powerful than the other, let's call it the Thinkpad), I will first attempt to get the less powerful one to publish the Kinects data to the Thinkpad, so it can then run a SLAM algorithm, teleoperation, etc.
• If this does not work, I will simply mount the Thinkpad onto the robot and do the computation on board. The robot could then perhaps be controlled by another computer through VNC, or SSH (although VNC is more useful, as a GUI is of course a nice thing to have when you want to actually see the robot mapping it's environment)
• I will most likely implement the RGBD-6D-SLAM algorithm that can be found here, it utilizes both ROS and the Kinect, and allows for full 3D mapping and localization. i will have to find out how to extract the robot's perceived position in the map, and a way to implement a navigation algorithm. Another problem is presented, again, by the enoumous amounts of data produced. After a few minutes, these 3D point clouds can be as big as several gigabytes.
  
• The alternative SLAM algorithm is this 2D-SLAM, which is nice because it is simple to use and has navigation already implemented, however it was made for the TurtleBot, so I'd have to re-code most of my robots steering (i.e. how the Arduino receives and interprets commands). Also, the algorithm needs odometry, which ROAMR doesn't currently provide. however, in comparison to RGBD-6D-SLAM, the maps produced by this algorithm should be much smaller in filesize, and perhaps more CPU (and especially GPU) firendly.

Diagrams and pictures soon, then this will perhaps make a lot more sense.

ROAMR now has a Git repository - and a name!

I've set up a Git repository for my robot to make sharing (and updating) the code easy. I've also given it a name: Remotely Operated Autonomous Monitoring Robot - ROAMR.
It's not really autonomous yet, but that's where I'm headed with it. As of now, the repository includes all code I've written for the project, and a readme explaining roughly how to use everything. If you have any questions, just leave me a comment here or post an issue on the Git page.

https://github.com/phdowling/ROAMR

Robot schematic and Arduino sketch

Last week I posted some pictures of a robot I've started building, at the moment it's really just a remote controlled car. I've put together a schematic showing the various pin connections. I use an Arduino Uno, an XBee radio, and an L293D motor driver chip, as well as two motors (mine are 9v).

Blue and red obviously represent power and ground lines, green connections represent digital or PWM signals from and to the Arduino, and the magenta lines are PWMs from the L293D, I chose a different color because they will run at a higher voltage than the Arduino PWMs, and they power the motors.

On the Arduino, I'm running the following sketch:

char index;
char serialbuff[7];
char ch;
int x=0;
int lSpeed;
int rSpeed;

int LMOTOR_DIR = 12;       // Non PWM pin for direction control
int LMOTOR_PWM = 11;       // PWM controlled pin.
int RMOTOR_DIR = 7;
int RMOTOR_PWM = 6;


void setup() {
Serial.begin(9600);

// Set the pins to output.
pinMode(LMOTOR_DIR, OUTPUT);
pinMode(LMOTOR_PWM, OUTPUT);
pinMode(RMOTOR_DIR, OUTPUT);
pinMode(RMOTOR_PWM, OUTPUT);
// And set these to a initial value to make sure.
digitalWrite(LMOTOR_DIR, LOW);
digitalWrite(LMOTOR_PWM, LOW);
digitalWrite(RMOTOR_DIR, LOW);
digitalWrite(RMOTOR_PWM, LOW);
}

void loop() {
 switch(x){
   case 0:{
     ch=(char)Serial.read();
     if(ch=='s'){
       x=1;
       serialbuff[0]=ch;
       index=1;
     }
   }
   break;
  
   case 1:{
     ch=(char)Serial.read();
     if(ch!=-1){
       serialbuff[index]=ch;
       index++;
       if(index==7){
        x=2;
       }
     }
   }
   break;
  
   case 2:{
     if(serialbuff[6]=='e'){
       x=3;
     }
     else{
     x=4;
   }
   }
   break;
    
   case 3:{
     if(serialbuff[1]=='+'){
       digitalWrite(LMOTOR_DIR, HIGH);
       lSpeed = 255-serialbuff[2];
     }
     else{
       digitalWrite(LMOTOR_DIR, LOW);
       lSpeed = serialbuff[2];
     }
     
     if(serialbuff[3]=='+'){
       digitalWrite(RMOTOR_DIR, HIGH);
       rSpeed = 255-serialbuff[4];
     }
     else{
       digitalWrite(RMOTOR_DIR, LOW);
       rSpeed = serialbuff[4];
     }
     
     analogWrite(LMOTOR_PWM, lSpeed);
     analogWrite(RMOTOR_PWM, rSpeed);
     
     x=4;
    }
   break; 
  
   case 4:{
     index=0;
     x=0;
   }
   break;
}
} 

As you can see, the Arduino will read its serial port (the XBee) for the character "s", which will indicate the start of a control packet. once it's found this, it reads the next characters, these will make up the rest of the packet:

• serialbuff[1] is either "+" or "-", indicating the direction of the left motor.
• serialbuff[2] is the speed of the left motor and can be between 0 and 255
• serialbuff[3] and [4] are the same as [1] and [2], but for the right motor
• serialbuff[5] will eventually act as a checksum, though I haven't implemented this properly yet
• serialbuff[6] must be "e" to indicate the end of a packet, otherwise the packet is discarded and loop restarts

You can see from this that the direction and speed of both motors can be completely controlled remotely, which gives us more opportunities as to how to steer the robot. For instance, instead of just using arrow buttons of the computer keyboard, one could write a script that converts accelerometer data (e.g. from a phone) into the appropriate motor speeds, allowing the robot to effectively be controlled through a phone.

Next up: the PC side script that sends packets to the robot.

Coming soon..

This is the platform for a small robot I'm building. It's remote controlled using XBee RF chips, onboard is an Arduino Uno. I plan to add a mount for my Android phone, for things like a webcam feed and sensor/GPS polling. Schematics and code soon!