Project Logs

Collapse

• Version 1: system ready

  Radu Motisan • 07/16/2017 at 19:03 • 0 comments

  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:

  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

• Version 1: ultrasonic beacon

  Radu Motisan • 07/16/2017 at 19:02 • 0 comments

  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:
  

  
  

• Version 1: Perfecting the design

  Radu Motisan • 07/16/2017 at 18:58 • 0 comments

  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:
  

  
  

• Version 1: Success!

  Radu Motisan • 07/16/2017 at 18:52 • 0 comments

  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.
  

  
  

• Version 1: GPS Errors and the ultrasounds solution

  Radu Motisan • 07/16/2017 at 18:50 • 0 comments

  April 08, 2013: As I've shown previousl, 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...

  Read more »

• Version 1: Bluetooth remote control

  Radu Motisan • 07/16/2017 at 18:46 • 0 comments

  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.
  

• Version 1: The H-Bridge

  Radu Motisan • 07/16/2017 at 18:42 • 0 comments

  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.

• Version 1: GPS/Bluetooth Interference

  Radu Motisan • 07/16/2017 at 18:39 • 0 comments

  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.

• Version 1: The Atmega128 microcontroller

  Radu Motisan • 07/16/2017 at 18:33 • 0 comments

  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.
  

  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.

• Version 1: assembling the chassis

  Radu Motisan • 07/16/2017 at 18:27 • 0 comments

  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:
  
  

View all 11 project logs