Designed and built the arena!  Details up at http://defconbots.org/defcon17/arena.php

Wall Following

So now we have the bot, we have servo control for steering (throttle is still on the R/C remote), we have sensors to detect right hand walls.

To follow a wall, you simply want to turn towards the wall if it's away from you, and away from it if it's going to be in your way.  Sounds easy, right?  The biggest problems we're running into is the delay between sensor data and the servo actually moving.  It either makes a continuous sine wave path, or the delay is too much and it turns into a wall before detecting that it should turn away.  So that's what we'll be working on for the next few sessions!

All the code for the work up to now is available at http://defconbots.org/defcon17/example/

Calculating the wall angle

Now that we have a reliable sensor platform, we need to calculate the actual angle that the wall is at.  The biggest problem here is bad sensor data.  The IR sensors spit out values that can vary widely, even when nothing is changing.  You'll see 40cm, 20cm, 38cm, 35cm, 80cm from the same sensor.  So first that needs some smoothing.  I simply took the last 8 readings, threw out the max and min, and then averaged the rest.  The sensors run at 500Hz so the delay shouldn't be noticable.

Second, when the sensor doesn't see anything it spits out weird values.  So even though the sensors are rated for 80cm, I found they didn't give reliable data (they give values when there's nothing there) past 50cm.

So, first smooth out the values, then throw out the readings that are too far, then you can calculate the angles they all make.  Take the average of that, and that gives you the "best guess" of the current angle the wall makes.  First I wrote and debugged all that using the Processing gui since it was *much* easier to visualize the geometry.  Then I converted that code into the Arduino code so that it could run directly on-board the bot.

It worked great!

Next sensor idea

The next idea was to array them just facing to the right.  That means we wouldn't be able to switch walls to follow, but at this point following A wall is more important.  In order for the software to be able to correctly calculate the angle the wall is at, it needs to know precisely what angle the sensor is mounted at.  So I put in a lot more work machining a precision mount that put the sensors at exactly the angles I wanted.  Unfortunately, that also did not work at all.  The wires got in the way, the mill couldn't hold the part and still cut the angles.  Basically it was a lot of work for something that ended up failing completely.

It was then that I realized that I didn't need to know the angles beforehand, I only needed to be able to figure them out later.  So I took a simple piece of PVC pipe and eyeballed the mounts, generally at 0, 23, 45, 66, and 90 degrees.  After that it was a simple matter of putting a wall at exactly 90 degrees, then viewing the sensor data which let me calculate the triangle which gave me the angle the sensor was at!

Fortunately the code I had written to debug the previous two sensor ideas was robust, and it was a simple matter to change the angles the sensors were displaying at.  That verified that the angle displayed on screen was the same angle the wall was at.

Testing Sensor Ideas

I think the biggest problem we're having with following the wall is that the sensors aren't getting good data.  The old design had one 80cm sensor pointing left at 45 degrees, one ahead, and one right.  That leaves a big dead spot out at 80cm where we can't detect anything.  So by the time we finally get a hit on the front sensor and the right sensor, it's too late to make the turn.

So, my first idea had 5 sensors.  One ahead, two right, and two left.  The goal was to be able to calculate the wall angle more often, since the "rays" were calculated to cross at the max distance.  So I put a lot of time into machining a very precise mount, then put a lot of time into writing the software to display and calculate the angles.  Then it didn't work at all.  The sensors are just not reliable enough individually to be able to calculate any angles far enough away to be useful.

Interpreting Sharp IR sensor values

We're using the Sharp 2Y0A021YK IR sensors (10cm-80cm), but unfortunately it's not a linear output.  The datasheet has a graph, but it's print-only, they don't give you either values or a formula.

So, I plotted out about 50 points, put them into an excel spreadsheet, built a XY chart out of them, then used "Add Trendline" to get a line that fit the graph, and then got the formula from that.  So now we have the function that converts the voltage the sensor puts out into the actual distance (sure would be nice if this were on the datasheet)

dist_mm = 1085534.81 * (float)pow((float)voltage_mv, -1.2);

Where voltage is in in milivolts, and the returned distance is in milimeters.

Really sharp, put this on your datasheet!

Kallahar

First code

After all the parts came in we had to put them together.  Some soldering was involved to connect the vehicle power to the arduino board, to put in a power switch, and how to mount all the sensors and board and everything.  None of it was complex, just some detail.  If I can create a "kit" that has all the wires and such that a team would need then you wouldn't even need to solder to enter the contest.

The first software read the IR sensors and spit out the values, we used that to make sure they were working at all.  Then we got the servos working.  Then a simple routine to try to keep the wall distance at a set value (too close, turn away, too far, turn towards).  We left the speed control on the remote, and let the software control the steering.

We built a little course using whatever white flat surfaces we could find, then started debugging what went right and wrong.  It turns out that the angle the wheels can turn out is really important when trying to figure out how much to turn.

Kallahar