Adding Ping Ultrasonic Distance Sensors, So It Don't Go Boom!

I'm adding ultrasonic distance sensors to my telepresence robot to keep it from running into walls or other obstacles which may damage it. Ping ultrasonic sensors use sonar to create a pulse that it can read by sending a signal out and seeing how fast it bounces back. In my code, I generally say if the sensor returns a value that is under 20 centimeters, then cut the motors. I have yet to figure out what happens once the robot is within that 20 centimeters. Since the power to the motors is cut, how am I going to get out of that situation? I've got a couple ideas but want to think about it a little more. 

I've got two sensors working really well right now. They both work completely independent of each other and they don't interfere with the motor code that's on the Arduino Mega. So far everyone's playing nice together. I found a library that allows an array of sensors to work together and so far, it's doing everything I want to do with the sensors. It's called NewPing and can support an array up to 15 sensors.

Parallax sells these sensors for $29 but I found them on ebay at 5 for $10. I plan to have 4 total; two in the front at about 20 degree angles and the same for the back.

Proof of concept for the sensors. The finished product will look way better.

First Steps .. or Revolutions.. or Trip!

My robot (still don't have a name for him) went for it's first stroll tonight. I was stuck for over an hour because I wasn't able to successfully able to upload a sketch to the Arduino Mega. Since the Arduino Mega is connected to the Raspberry pi via USB, I am able to program it straight from the Raspberry Pi. I do this by installing the Arduino IDE, and VNC Server on the Raspberry Pi. Then I downloaded the TightVNC Client to my windows machine. I start the vnc service on the RPI and then boot up the client on my windows machine which takes me to the UI interface that RPI has. I can then access the Arduino IDE just like I do on Windows.

There is a caveat to this setup. Because I'm using the 'php_serial.class.php" so the webServer can write to the RPI's serial port, I need to put a capacitor between the 'reset' and the 'gnd' on the Arduino to keep it from resetting each time the PHP serial class closes it's connection. This is interfering with my communication between the webServer and the Arduino. I was successfully getting the command from the webServer to the Ardino, but I wasn't able to read my acknowledgement back from the Arduino to the server so I could display it. So this work-around works and it was the capacitor that was not allowing me to properly upload my sketch from the IDE to the Arduino. I finally realized it, pulled the capacitor long enough for it to upload and put it back on. Works like a charm now.

Wheels and DC Motors

 

After doing a couple night's worth of research, I settled on the Parallax 7.2V Motor, Bracket and Wheel Kit. The wheels on the website were blue but when my order came in, they were orange. Turns out that I think they look really cool so I'm glad! I believe these are exactly what I was looking for.

 

 

 

 I had some concerns with mounting the wheels to the platform. If I was going to drill the holes manually, I would have to make sure they were perfectly straight or else they would be out of alignment causing them to fight each other when moving. So in my Solidworks model of the platform, I added the holes. This would ensure that the holes would at least be straight on the platform. Putting bolts that are too thin would also increase the chance of them not being aligned also so I made sure that I used the largest possible bolts.

 

The Platform and Back Wheel Support

I was banging around different material for the platform and I know that I will be going through a couple iterations. I knew that plexiglass would look cool but I questioned the stability of it. Turns out that it's not too bad at this point.

 

 

The back wheel support was a design that I made in Solidworks and printed on a Solidoodle 3. The idea with this is that the dc motors would connect to the front wheels and they would also be responsible for steering. The back is a ball caster, allowing the robot to do a true 'turn on a dime'. My first robot had wheel casters and they worked but the problem with them is that if the wheel is at 90 degrees from the front wheels, if you wanted to move forward, you would not be able to go in an immediate straight line until the caster straightens out. The ball caster eliminates this problem. 

 

 

 

 

The file created for the back support ball caster.

Going with Raspberry Pi for HTTP communication

This is going to be the heart and soul of my project; the communication platform that allows the end user to communicate with the robot. Without a solid, reliable solution, the robot could be banging into walls or falling down steps because vital data couldn't be transferred reliably.

With the need for wireless communication to the internet router, I needed a WiFi solution. Since I know the Arduino platform pretty well now, I naturally wanted to stick with what I knew so I got an Arduino WiFi Shield and immediately ran into problems with it. The problem was multi-layered. There were multiple versions of the hardware, multiple versions of the WiFi libraries, multiple versions of example code and multiple versions of the IDE. You could only run some of the examples on 1.0.5 of the IDE and of course some of the libraries only worked with some of the hardware versions.

I actually got it to work, where I was receiving HTTP requests and serving up HTTP responses but the success was short lived due to buffer overruns, unresponsiveness and just general problems. I've played around with a Raspberry Pi in the past but have never really done anything with it. I did put Apache on it and served up some pages and it seemed pretty stable so I thought I'd give it a shot.

I had a couple concerns. One was the learning curve. I know Unix, but just enough to get work stuff done at work (building/deploying applications and writing kornshell scripts). I just never considered myself a unix guy. Their cryptic commands just really erked me so I stayed away from them. The other concern I had was how was I going to translate HTTP arguments over to Serial commands. Sounded like a pain in the butt and I didn't want to have to mess with it. I knew Arduino so I wanted to stay in that camp. When I knew that couldn't happen I thought I would give it a try.

What I ended up with was a pretty efficient way to communicate HTTP data to the Arduino via the Serial port using a USB connection. I had a couple connection options to the Arduino, I2C, UART or USB. USB I read was the easiest and since these two boards are going to be together for the entire project, I didn't see a need to mess with the other options. Hardware connection, solved. I got Apache2 up and running on the RPi so now I just needed a way to talk through it's Serial ports. I found some Python libraries that talked to the ports and did some tests and it worked. Python just seemed like an awful lot of overhead for what I wanted to do. Then I ran across this post which said you could connect your RPi to an Arduino through PHP. That seemed like a much cleaner approach so I tried that. Using a class called PHP_Serial, I was able to send data to my Arduino causing a blinky light to blink. I knew I had broken through and that this was most likely the way I was going to move forward.

One caveat was that I would have to do all of my Arduino development over on the RPi because I would need to see the Serial Monitor for debugging purposes. Since the Arduino was connected to on of the USB ports on the RPi this was the only way to go. I read that it was a pain in the butt to do but I just ran 'sudo apt-get install Arduino' on my RPi and viola, a JRE was installed and after 3 minutes or so, I had a working version of the Arduino IDE on my RPi. Pretty slick! =)

So that's where I'm at for now. I just made a backup of my RPi image, documented my findings and progress here. Now, time to do some tests with my new communication configuration!

Building a Telepresence Robot.. and documenting it.

Version 1 of my Telepresence Robot

This isn't my first time at the rodeo. Last year, I built a Telepresence Robot for fun and just to see if I could do it. Well I did, and I went to RobotFest and showed it off. Kids loved it and their parents were curious. It was a great project and this time around, I want to have it planned out much better. 

The specs on this were pretty basic:

• Nexus 7 Tablet that controlled all of the Audio/Video communication through Google+ Hangouts.
• A tripod that I swiped from my fathers telescope.
• A kid's toy spaceship was used as the base. 
• Two DC motors that were at my Hackerspace.
• Arduino Uno that controlled incoming serial communications for handling of the DC Motors
• Arduino Motor Controller controlled the power from two NI-MH batteries that powered everything except to the tablet.
• Wansview IP Camera - This was really the hub of the project. Not only did it have a camera, it also had a built in web server along with non-advertised, serial out comm ports that you had to hack into from the bottom of the device. 

I gave a presentation at RobotFest that explains exactly how this worked. I've got a lot of work to do for this next version and I'm just now starting my design and analysis. Should be fun!  =)