328eForth

Just checking in:  offete.com seems to be a defunct website now.  However, 328eForth seems to have more than one iteration on GitHub, so it still exists.

Oh, yes, and a big middle finger to the European Union for its laws about this or that nonsense.  I don't use cookies on this website, and if Google does, that's their business.  However, I don't like European bureaucrats telling me what I have to do.  I'm an American, and proud to be so.  So, Eurocrats, Bite Me.

Burned out Arduino recovered

This doesn't have anything to do with the RaPiArbot, but a few weeks ago, I was asked to look into putting FORTH on an Arduino Uno.  It was for a project at work.

I was able to get a working implementation of 328eForth on it by using one Arduino to program another. (www.offete.com has been reorganized, so I'm not sure where to get the 328eForth image any more.  I think you can e-mail them.)

I had tried using a USBtinyISP AVR Programmer to write the Arduino, but in the end it turned out to be easier just to hook up one Arduino as a programmer for another Arduino.

In order to make sure it was working safely, I also reprogrammed the bootloader of the Arduino with Forth back to the original Arduino bootloader.  I wanted to be able to recover my own Arduino after I was done playing with Forth, and I was successful at restoring the Arduino.

Then, on a whim, I tried restoring the bootloader on the Arduino that had been burned out, and it ended up working again.

So... nice.

Arduino restored, robot demoed at the hobby store

I got the Arduino board replacement on Wednesday, and everything worked out fine.  I can't tell if the ultrasonic range finder burned out a little or if it is just as crappy as it always was.  I won't bother replacing it, though.

It turns out that the new rubber tires I got from the hobby store are a little too grippy.  Because the tires require at least a little slippage when the robot turns (rotates), the robot can't turn at all because the tires simply don't slip on our floor.

So, last night, I decided to return to the hobby store to see if I could buy a different set of tires that maybe had better traction than the original tires but less traction than the ones I bought on Monday.  I also decided to bring in the robot, along with my old Airport Extreme Base Station and MacBook Pro, so I could give a demonstration.

I got there just before closing, which was at 7 PM.  A few customers came by to ooh and ah at the robot on the counter and ask questions, but extremely embarrassingly, I couldn't get the robot to run because I couldn't get it to connect to my base station.  My MacBook Pro was able to connect, and it could see that there were about a dozen other WiFi stations in the immediate area, so it must have been interference that was causing the Edimax WiFi dongle on the Raspberry Pi to have problems.

Then, right at closing time at 7 PM, the Raspberry Pi finally made contact.  I think the nearby Makerspace shop must have closed up and shut down its own WiFi access points, cutting down on interference.  There were only the three store staff people left in the store, but I was able to run the robot around a bit and show them how it worked.  I was also able to show them how the original tires slipped on the floor, so the guy who specialized in RC race cars was able to find a pair of racing tires that were softer than the original tires but harder than the tires he sold me earlier in the week.

I think the new tires will do nicely, but I also think that the best thing will be to switch tires depending on the surface the robot will drive on.

Burned out my Arduino Uno

Crap.

I took apart the robot to put some Velcro on the big battery today, and I had to disassemble the electronics to get inside.  When I reassembled it, I accidentally reassembled the wiring incorrectly, without noticing it, and I short-circuited the 5 V line to GND when I connected the ultrasonic range sensor.  A minute or so after I turned on the power, I smelled something like melting plastic.

I have some spare parts to test, but I'll likely have to order at least a new Arduino Uno.

-----

Update:  Based on my test with a spare Arduino Uno R2 board, it's just the Arduino Uno R3 board that burned out.  The Arduino Motor Shield R3 board seems fine, the Wireless SD shield wasn't really being used, the ultrasonic range sensor seems more-or-less fine, and the Raspberry Pi seems fine.  A test of the robot with the Arduino Uno R2 in place seems to indicate the function is normal, though I don't recall if the Arduino application had never said usbmodem as the serial port on the Raspberry Pi.  Regardless, it seems to upload properly to the Arduino.

The burned-out Arduino Uno R3 smells kind of funny, like melted epoxy.  I ordered a couple more from Amazon; they're about $8 cheaper than at Radio Shack.

-----

On a different note, I went to a local hobby store after work today and picked up a set of soft racing tires to replace the hard tires on the robot.  These fit the wheels, and they should provide better traction.

When I mentioned that I was using them for a robot, the guy who helped me find the tires asked me to bring the robot in to show him.  Unfortunately, he'll have to wait for me to rebuild it, now that the Arduino Uno has burned out.

New Demo Video

In this new demo video, I show my Raspberry Pi Arduino Robot approaching a cardboard box and scanning it with the ultrasonic range sensor, twice.  Unfortunately, I didn't properly save the first scan image file, so it doesn't show that the distance measured was ~10 inches from the range sensor.

Also demonstrated in the video is the onboard video, shown as an inset, picture-in-picture video.  The field-of-view isn't great.  I suppose I could angle it better, but when I drive the robot at home, it's on the floor, where its angle points sort of upward and looks okay.  Also, here, I could have adjusted the FOV electronically.  However, for privacy's sake, I was also trying to block out the view of the rest of the room.

After backing out, the robot had a power glitch (described below).  Power came back after I jostled the robot a bit, and then I drove it around a while.

Some notes:

-- I've been experiencing sporadic power loss to the motors whenever I run across bumpy surfaces.  If I pick it up or otherwise move it after it loses mobility, it often regains motor mobility.  I think I may have a loose wire somewhere inside the robot platform.  The battery pack is not secured inside, so if it slides around, a connection could loosen.  I think I'll tape some velcro to the battery pack and the bottom of the robot platform, so I can secure the battery pack.

-- The angular resolution of the ultrasonic range sensor is just awful, and I don't think I can buy another one that's any better.  Just looking over sensors in roughly the same price range on Amazon and Radio Shack, I think they're all almost exactly the same cheap/inexpensive design.  It's almost not worth using such fine step sizes on the stepper motor, and I thought I was using a relatively coarse step size to begin with.  I could try making some sort of collimation device for the sensors, but then I think I'd lose distance resolution.

-- 7/28/14 Update:  It turns out there are ultrasonic range sensors that are much cheaper than the Radio Shack range sensor, but most of these seem to use four pins instead of three.  At this point, I'd rather not have to figure out how to make use of the additional pin.

-- The robot itself is still not autonomous.  I still control it from my MacBook Pro via WiFi.  Now that the ultrasonic range sensor works, at least in a rudimentary way, I think it's time to build in some basic AI.  Collision-avoidance is the obvious first step, and since the angular resolution is so poor, I can make the sensor sweep faster by taking fewer steps.

-- You can also see from the video that the wheels slip a lot on some surfaces.  If I could buy tires with better traction or just a lot less slip, I could trust velocity estimates a bit more, and maybe I could program a little drive-to-destination AI, too.  That would be one advantage in using a Raspberry Pi as the brains of this robot over just using the Arduino alone.

-- If the Arduino plus Tamiya Tank platform robot was my version 1 robot, and if this is my version 2 robot, then maybe it's about time to consider a version 3 robot.  In addition to adding AI capability, I think it's time to consider additional physical capability.  I think I'm down to maybe only one or two remaining digital I/O pins on my Arduino stack.  I might be able to add another sensor, but I wouldn't be able to add another stepper motor, servo motor, or a robot arm (which, BTW, I have already assembled from a kit!).  So, to add more stuff, I would want to expand with more digital I/O pins.  One way to do that would be to add another Arduino stack.  But how?  A possibility might arise from the fact that I chose to go with USB as my means of communication between the Raspberry Pi and the Arduino, rather than using the GPIO ports as others have done.  If I can use a USB hub off the Raspberry Pi, then theoretically, I can communicate via USB with multiple Arduino boards, provided the Arduino serial libraries and the Raspberry Pi serial libraries allow for addressing through multiple USB devices.

-- Plus, if I go with expanded physical capabilities and multiple Arduinos and a USB hub, I'll definitely have to go with yet another, larger robot platform, one that can hold larger battery packs with much higher watt-hour ratings, which means the Arduino motor shields will have to drive relays rather than provide those voltages directly.  Then I can drive more powerful motors needed to drive the larger platform, but then the larger platform can hold my robot arm...

The range plot

After a little bit of tweaking, this is what the range plot looks like.  0 degrees is roughly straight ahead of the robot, and 90 degrees is to the left.  (Unless my memory has things reversed...)  In this scan, I'm sitting roughly in front of the robot as I'm testing out the scan, so you can see that I'm sitting roughly 20 inches in front of the robot at the height of the sensor (with the robot sitting on the table).

Unfortunately, it takes about 30 seconds or so to run through the scan and put up the plot in Python, and that's with a direct Ethernet connection to the already-slow Raspberry Pi.  Imagine how slow the response will be over wifi.  Still, it works, so that's something.  I suppose I could have bought a faster stepper motor, but I was going cheap -- <$4.  I had to tweak the delay time between steps and make the delay longer and longer, because shorter delay times caused the steps not to be always repeatable -- after multiple cycles, I ended up not returning to the same starting and stopping positions, which you don't want with a stepper motor.

Ultrasonic Range Sensor Scan Demo

Here's a video of the range sensor scanning back and forth.  I finished the code to do a twenty-one point scan across approximately 160 degrees or so in front of the robot and return a Python display of range points.  The display doesn't look all that great, in my opinion, but at least it shows if there's something pretty close to the robot.  I'll do a bit more tweaking, I guess.

Soon, I think, I'll put up more video.