Featured on Hack A Day, check it out here!

My friend Kevin, contacted me for building an advanced autonomous companion robot. The final goal is to make the robot follow you. This is the construction log page, with more content added as the project moves on. As this project continues what I have shown in a previous article, you can see this post a a follow-up, named as Part2.

1. January 21, 2013

Kevin carefully prepared everything for the long trip, and the package with the hardware components got here today. For the new robot I will drop my previous Ara robotic rover platform, in favor of the neat A4WD1 from Lynxmotion. Essentially this is a similar differential control rover platform, using 4 geared motors of 200RPM 37mm diameter, one for each wheel (HN-GH12-2217).


Putting the rover together was easy except for the tires which required a little Vaseline. The robot’s central processing unit will be an Atmega128 microcontroller and not the Lynxmotion’s BASIC Atom Pro 28 Pin (which also requires the custom “bot board II“). Atmega128 wins here with its 128KB flash memory, 16MHz max operating frequency and a multitude of IO ports, while the Basic atom pro can only provide 32K of Program Space and a limited operating frequency (Not to mention the costs, Lynxmotion products are also very expensive).
The motors are to be driven via a Sabertooth 2X12 R/C Regenerative Dual Channel Motor Controller . I am yet to see how well this performs when compared to my simple H-Bridge that I used before. The battery is a generous 12V 2800mAh from Lynxmotion.

2. February 06, 2013

The rover’s bottom is a thin black plexiglass sheet, that looks great but can’t sustain much weight. In this case, the battery seemed a bit too heavy for the bottom sheet, especially considering high speed movements over rough terrain. So I had to build a battery holder using some steel. Hope I won’t get to replace all the original rover by the end of this project 🙂 . But this is what perfectionists usually do.


The steel support is placed longitudinally at the bottom, fixed in screws. This can be used to support other components as well, as I drilled multiple holes for that. Two U-shape holders have been fitted using rivets, this way I got no difference in level, and no sharp points to puncture the battery to be placed in this support:

The prominent ends have been leveled with a metal file. The U-shaped holders got some little plastic spacers, made from PVC plastic heated and bended in a convenient angle. With the battery in place, here is the first motor test:

3. February 12, 2013

The Atmega128 board got a power supply, for both 5V and 3V. The latter is for the Bluetooth module and one of the GPS modules.

The power supply consists of a high efficiency DC-DC converter built using the LM2596 IC. There are plenty of such converters available on Ebay for just a few bucks. I replaced the pot with a fixed 1KO resistor, so the converter would put out a fixed 5V voltage. The 3V is obtained using two L78L33 ‘s. The power boards where fixed to the Atmega128 board.

4. February 18, 2013

New Atmega128 board, with pin connectors including power and gnd to make connections easier. The microcontroller board has been mounted to the robot’s platform. The Sabertooth 2X12 has also been mounted. Thick wires link the h-bridge and the motors.

5. February 25, 2013

I finished the top board, exposing the bluetooth UART module and the NMEA GPS module. This will be mounted outside the robot’s body, to make sure the modules get maximum radio signal. An LCD is to provide vital information such as battery levels and other diagnosis messages.

And with these last modules, I had to write a considerable amount of software. And this is only the beginning of the long road ahead:
– HD44780 LCD code . The LCD uses only 3 wires to connect to the Atmega128, using a shift register, 74HC164, to save a few IO pins.
– UART code, to handle data from the UART Bluetooth module and the UART GPS Module.
– GPS NMEA Parser, highly optimized to save memory and processing power. Also available on Google code, here.
And the first problems didn’t wait too long to show up. It appears the bluetooth module’s RF creates some kind of interference that reduces the GPS signal. As a result, having the Bluetooth module on, I can barely get a GPS fix. When the signal is good (8 satellites in use), turning the bluetooth module on will reduce the signal (3-4 satellites). Here is a demo to show this defect. The red jumper wire is used to power on/off the Bluetooth module. The “sats” value displayed on the LCD is the number of fixed satellites.

So to bypass the issue, I’ll need to rework the top-board and move the Bluetooth module at some distance from the GPS module. I was not aware of such a design requirement.

6. March 27, 2013

The Sabertooth 2X12 R/C Regenerative Dual Channel Motor Controller needs to be hooked up to an UART port. On the microcontroller board I have no free UART port available, so to simplify I plan to use a dual H-Bridge built from scratch. You can see the Dual H-Bridge here.

Schematics and PCB available in the Dual H-Bridge article.

The LCD has been mounted inside the chassis, must admit it looks perfect this way: low profile, high tires, black paint, and that blue electric LCD light. All combined with a highly energetic movement.

7. March 28, 2013

Following the successful dual HBridge integration, I added the Bluetooth UART module, and wrote a software for Android OS, to allow me to control the robot by using the phone. Here’s a demo video:

And a few pictures to show the final robot shape:

Next thing to do is to make the robot follow the user, AUTOMATICALLY! I’m currently considering two options, one involves using the GPS Module, send the coordinates via bluetooth to user’s mobile phone that also has GPS and can then inform the robot where it needs to go, the second option would be to use some kind of beacons, the user would carry in his/her hand (or pocket), and the robot would detect those and follow the signal.

8. April 08, 2013

As I’ve shown above, the purpose of this robot is to follow its user, and I imagined two instruments for implementing that:

1) a global localization method, using GPS. The PROs are that we can place a GPS module on the robot, and the user can have a mobile phone with its own GPS module. The phone can establish a connection to the robot using Bluetooth, and send the user coordinates periodically. Then the robot can calculate the path it needs to run, to get in close proximity of the user, and follow him/her. Sounds good, but the CONs are bad: first, the GPS errors are too big to allow us to make the robot follow the user; it would rather jump like a crazy monkey all around the user, and this is the best scenario. Another issue is also the GPS signal which is poor or unavailable indoors.
If we place a stationary GPS receiver, here’s how the GPS coordinates look like:

As you can see, despite the fact our GPS receiver is stationary, the localization data we receive has a tolerance of a few meters or even tens of meters, placing us on a disc surrounding the real position. This is inappropriate for the purpose of this work, so I have decided to find different means of robot positioning and orientation; this number -2- below:

2) The local method will use a closed system for localization, formed of only the robot itself, the user, and a signaling beacon. Normally the user will carry a signaling beacon (ultrasonic, infrared, radio, etc), which the robot will “see” and follow. Easy to say, doing it is of course much harder, as we need a smooth robot movement, so a lot of error compensation and fuzzy logic must be involved.
Recently I made some excellent progress using ultrasounds as a transmission method, to create a simple beacon detector. You can read more on it here.
The user needs to carry this tiny, low power ultrasonic beacon which the robot should be able to “hear” and use the signal to navigate to the target, and follow it.

These wonderful modules will not only return a signal when ultrasounds are detected, but the output amplitude is directly proportional with the actual distance to the beacon. So we’ll know both where the beacon is, and how far.
Given these tools, there are several ways of implementing the working mechanism:
a) using a single ultrasonic receiver, placed in front of the robot: the rover will need to rotate until it detects a maximum level of signal. Then it should move forward until the detected signal reaches a given threshold (so it will not hit the user, but stop right before him/her). It doesn’t really work well, as the software gets overcomplicated and the results are not as good as expected.
b) similar to a), but use a servo motor to rotate the ultrasonic sensor instead of rotating the entire robot. When the maximum signal is detected, the robot should turn towards the source, and begin moving forward . It still doesn’t solve many of the issues found with a)
c) using two ultrasonic receivers, placed some space apart, in the frontal part of the rover. Now we can make differential measurements, so it’s easy to know from which part is the signal coming from, as the corresponding sensor will have higher readings. The robot can now directly turn towards the beacon, and follow the forward direction while the two sensors give approximately similar readings. If the right sensor output increases, then it means the robot needs to turn right, to face the beacon and continue moving forward. Same case for left. A similar approach has been used in a project by Andrew Wiens :

d) using more than two sensors, ideally 8, placed at 45 degrees in a radial disposition. This would pinpoint the source more accurately, and reduce the time needed to find the beacon. Still, to simplify, I plan to go for the differential measurements presented at c) .

The ultrasonic sensors already return an output signal which is a function of the distance to the beacon / user. This can be used to measure the distance. If greater accuracy is required, we can involve infrared light in the process:
– the beacon sends a set of 38KHz modulated Infrared pulses marking moment of time t0
– the beacon immediately sends out the ultrasonic pulses
– the receiver which is a few meters from the beacon, receives the infrared pulses practically instantaneously and knows the time is t0 (using a TSOPXX38)
– the receiver registers the incoming ultrasonic pulses at the time t1, where t1>t0. By using the speed of sound in air, we can get the exact distance to the beacon.
All in one we use light to signal the start for counting, and we stop when the ultrasonic waves reach the destination.
More on this here, here or here.

9. April 09, 2013

Using the ultrasonic sensors differential readings (with sensors placed in front, at angles of aprox. 15 degrees of the longitudinal axis), I got some excellent results: the robot is able to follow me, and keep track of my speed, and orientation:

The algorithm compares the readings from the two sensors and decides whether to turn left (if left sensor return higher readings), right or to move forward (if the output of the two sensors is similar).
There are some remaining issues:
– if the robot approaches a wall, and the beacon signal is coming from the back, it will reflect in the wall and confuse the robot
– no detection capabilities for signal coming from any other direction, other than the front
To solve these issues, three more ultrasonic receiver boards are needed, namely one for back, and one for each of the sides. Also the movement is a bit shaky, and this can also be improved by changes in the robot’s software code. More to follow soon.

I built some nice PCBs for the ultrasonic sensors, and provided more details on Detecting an ultrasonic beacon, here.

10. April 10, 2013

I built a total of 5 ultrasonic receivers, that are to be placed two in the front, one at the back and two on each side.

The idea is to have the robot turn around facing the ultrasonic signal, and then to make it follow the source using the two frontal sensors. The differential readings will help us decide whether to adjust the direction for left or right.
Using some PVC pipes, I built some nice and robust plastic enclosures, by heating and pressing the plastic to get the desired shapes:

The result looks great:

For some uber-coolness factor, I decided to add frontal white lights and back position red lights, controllable from the software (on/off). The frontal side now also houses a nice Sharp 2y0a infrared sensor, that will help avoid hitting any obstacles. So now the robot is capable to hear and see its surroundings. Love how it looks:

11. May 01, 2013

Time has come to build the TX ultrasonic beacon. This time I wanted to try something new, so here is my first PCB for SMD components:

It uses a NE556, dual timer, and is configured to emit short bursts of 40KHz pulses. You can see the circuit here:

Eagle file also available, beacon TX.
A case was also needed, to enclose the 9V battery as well, and make it comfortable for holding it in the hand. The final results looks like this:

12. May 03, 2013

This project finally comes to an end, so I recorded two demo videos to show the robot following me, outdoors. A few modifications in software are likely to be done, but all in one, the work is pretty much complete:
Demo 1:

Demo 2:

13. May 22, 2013

As I am a perfectionist with all that I build, I couldn’t stay away and had to make this robot even better. So I did two things:
1) For the autonomous, human following software: I improved the ultrasonic detection algorithm, and the movement logic: Now the robot will follow its user more precisely, and the speed will vary with the detected signal: if the robots sees the user at a greater distance, will engage with a greater speed. If closer to the user, will proceed with smaller steps. The calculations are not linear, so I used some time to get the best formula. In the end I’m quite pleased, we can see some nice improvements when compared to previous two videos – so here are two new demos:
Demo 3:

Demo 4:

2) For the remote control software, where the user controls the robot using a phone, the rover now reports its frontal sensor readings (that show the proximity in centimeters to any detected obstacle), to the smartphone. So the movement commands go from phone to robot, and the sensor readings go the opposite way, from robot to phone. The Android software now allows the user to turn the lights on and off, and using the frontal distance sensor, a red line is drawn, showing the proximity to an obstacle. The robot can be controlled this way – without actually seeing what it is heading for, as this simple radar will be enough to get a clear path. Here is another demo:

3) When bluetooth is connected, the robot will ignore any ultrasonic signals from its beacon. So better separates the two modes of operation discussed above.

Resources:

Mechanisms for Combining Infrared and Ultrasound Signals for Indoor Wireless localization
Infrared / Ultrasonic beacon
Ultrasonic Source Localization
Mobile Robot Navigation
Learn about GPS
Robo-Dog on Hack A Day