Note:
The name has nothing to do with vampires. I have never read/watched those books/movies and I have no intention to. The name is an acronym for Electronically Driven Wireless Autonomous Roving Droid.
Proccess
At my school in 8th Grade we get to do a project on whatever we feel like. I had wanted to build a robot, so I used this as an opportunity to do so. My sister's friend's dad owns a metal shop, and he offered to help me make the body. We worked for two evenings to make a CAD drawing of the body.
He cut it on his shop's water jet and then I helped him bend the parts into a chasis. Over the summer I had bought the parts:
- x2 Continuous Rotation Servo Motors from Parallax to drive the wheels
- x1 Hitec HS-55 feather Servo to turn the head
- x1 Parallax Ultrasonic Ping))) Sensor as the one and only sensor
- x1 Arduino Uno rev 3 for the brain
In my original plan I was going to use Xbees to transmit the destination x/y coordinates from the computer to the robot, but for some reason the Xbees would not work with the rest of the code. All test programs worked fine, but as soon as I created an instance of my class Robot, I got nothing on the Serial Moniter and most of time the rest of the code wouldn't work either. I also bought the Arduino motor driver shield, which is COMPLETELY unneccessary for driving motors using the Arduino. I mean, it has screw terminals and connections for a third party electronics project, so if that is what you want, spend an extra $30.
I wrote most of the program before the chasis was finished. This turned out to be a mistake, because then I had to debug over a thousand lines of code rather than writing a little, then testing it. After months, I finally removed about 50 error messages and uploaded the code for the first time. After waiting for my painfully slow computer to upload the sketch, I was greeted by a brilliant display from my robot of...
Nothing!
My first problem was that I was trying to use Arduino functions in my constructors of classes whose objects were being created before setup(). As I now know (after asking on the Arduino Forum), Arduino calls a function init() that does all the setup work for its functions. init() is called directly before setup() and so no Arduino functions I was using in the constructors was doing anything. The fix is to create some function that does everything the constructor normally does and leave the constructor empty.
When my robot still did nothing, I had to go bug hunting again. This next problem was that my sketch was using too much memory. I replaced many of my int variables with bytes and that solved the problem. Now the program actually ran...the robot into walls.
Almost every time! Because the Xbees weren't working, I had no debug information on why this was occuring. So I built a simulation of the robot on my computer. Instead of scanning with the sensor, the simulation asked the user for input. I added many output lines and was able to gain much valuable information. One problem was that in some places I was using the number set 1-4 for sides of a square and in other places I was using 0-3. The main problems I was having came from the fact that I had two systems of directions that were being confused for one another. I was representing cardinal directions with 0 for north, 1 as east, 2 as south and 3 as west. And for directions relative to the robot I was using 0 for front of, 1 for to the right of, 2 for to the back of and 3 for to the left of. I had to go through all the code multiple times to make sure I was using the correct set of directions everywhere. At last, the simulation got through a simple maze.
I transfered the code back into the Arduino IDE and uploaded it once more. Now the robot only occasionly ran into walls. The problems turned out to be with the algorithm that decided which way the robot was to go. Because my deadline was nearing, I simplified that code so that instead of using the Pythagorean Theorem to determine which direction would reduce its distance to the goal the most, it mearly went the first open way it found.
Logic
The current logic is as follows: Edward first checks to see if he's at destination. If not, he scans the walls to the three sides of him excluding behind him. He is currently scanning 5 times, dropping the highest and lowest results then averaging the rest. once he determines where walls are, he decides which way to go as follows. If there is no wall to the front, he goes that way. Next he will try right, then left, then finally goes back the way he came if there is no other option. The u-turning is untested in order to finish it in time for the deadline.
Next Steps
Now that my project is done, I have many things to add.
- Make Edward check for a wall behind himself as well
- If the square he is in has a wall, then so does the square on the other side of that wall. That needs to be recorded
- Testing what happens if Edward goes back the way he came
- Even though wireless is in the name, it was dropped due to technical difficulties. I need to reinstate it
- Lastly, I want to create a GUI showing what he knows and where he is from a bird's eye veiw (Will be implemented in new robot, see last update)
Update
My robot now uses the pythagorean theorem to navigate. it calculates the distance from one square in any direction to its goal and goes the way that reduces its distance to the goal the most. I had tried it before, but it turns out i was using the symbol for bitwise XOR instead of the to the power of function. I also made it so my robot went back to its original position after making it to its first goal.
I am now working on tranfering the code to the comuter and having it command the robot via XBEEs. The second video shows me controlling my robot from my computer. This will allow me to create a GUI on the computer easier because i will not have to transfer as much data. This will also allow me to use a digistump arduino on another version because it reduces the size of the program on the robot.
Update
I am able to command my robot with Dev-C++ but it is hard to get the timing correct. I also improved the algorithm so that it will take the same path it used to arrive at its destination to go back to its starting place. The third video is a culmamation of the improvements of this and the above update.
Update
The motors and wiring have become unreliable, and were never very good in the first place. I am going to continue the programming with my new robot, BEN (https://www.robotshop.com/letsmakerobots/node/37441). I am therefore declaring this robot finished.
Navigate Through a Maze
- Actuators / output devices: Continuous Rotation Servo Motors
- CPU: Arduino UNO Rev 3
- Operating system: windows XP
- Power source: x2 9v
- Programming language: C++
- Sensors / input devices: Ultrasonic Ping))) Sensor
- Target environment: indoor
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/edward-my-maze-walking-robot