# Jon's Place

## Sunday, December 29, 2013

### uCee - Of Rangefinders and ProxDots

So, today I've been working on uCee (note the slight spelling difference from my previous post - I like uCee as a name better than uC).

Specifically, I've been working on getting my range finders working in a reasonable fashion. I'm using three GP2Y0A41SK0F Sharp IR analog range-finders. I'm powering them with 5 volts, but since the maximum voltage they return is about 3.1 volts, I can hook them directly to the analog inputs on my Teensy 3.1, which allows a max of 3.3 volts on analog inputs.

However, as anyone knows who has used them, Sharp IR range-finders have a curious piece of behavior that occurs as the object being sensed gets close enough - the signal inverts, and starts acting as if the object is moving away instead of getting closer. For the sensors above, that happens at 30 mm away. I was going to use a ProxDot sensor in conjunction with the range sensor, but they trigger when the object is about 45-50mm away. However, since ProxDots have 2 IR LEDs, I tried covering one with a tiny piece of black electrical tape, so there would be only half the strength of light for it to sense. Sure enough, with one LED covered, the ProxDot triggers at almost exactly 30mm, which is perfect.

The code (without the ProxDot) is as follows:
float voltage = value * 0.0032258; // 0-1023 -> 0-3.3 volts
float exactDistance = (100 * ((1.25 / voltage) - 0.15));
int distance = (int)exactDistance;
if (distance > 200)
distance = -1;
So now I'm going to combine in the ProxDot sensor, and add a few lines of code:
float voltage = value * 0.0032258; // 0-1023 -> 0-3.3 volts
float exactDistance = (100 * ((1.25 / voltage) - 0.15));
int distance = (int)exactDistance;
if (distance > 200) {
distance = -1;
} else {
int proxDot = digitalRead(proxDotPin); // signal is low if something is sensed, high otherwise
if (!proxDot)
distance = max(0, 55 - distance);
}
And presto - I get a much more useful distance value at close ranges.

## Friday, December 27, 2013

### Roz - Walking Again

So Roz is now walking again, but this time with a Beaglebone Black running Python. I'll blog more of the details later, but for now here's a quick video:

## Wednesday, December 18, 2013

### uC (MicroCrawler)

So I've decided to call this robot uC, short for MicroCrawler. It is also a micro-controller based robot, so it fits double.

I got a 9-axis IMU and a bluemirf module in the mail today, and they fit nicely and look great. Here's a shot showing them mounted, with the proper gearmotors mounted, and the non-drive wheels temporarily attached. I'm pretty happy with how its turning out.

 uC Is a Small Robot...
My Teensy carrier board is being made at OSH Park, and I should get that early in the new year. Here's what it looks like:

 Teensy 3.1 Carrier Board
It has a lot of 0.050" spacing plugs, and uses all of the regular I/O pins on the Teensy.

I'm not going to be able to do much more to the robot itself until the carrier board arrives - I don't want to be soldering and then de-soldering wires from my sensors and h-bridge board, so I'll wait until I get the board to hook everything up. In the meantime, I'll be working on the software that will run on the Teensy, and possibly also I'll be working on the monitoring software that will run on my phone.

A few more random pictures:

## Sunday, December 15, 2013

### Yet Another Robot

So, while I was flying back home from RobotsConf (which was awesome, btw), I was paging through the copy of Make Magazine than they gave us. On page 64, I saw this cool little robot called CamBot, shown below.

 Cambot by Dave Astolfo
One of the issues I ran into with Roz while I worked on getting him walking was the constant need to reboot the Beaglebone Black, either because of USB issues or networking issues or power issues. I decided I wanted a robot to play with that went back to using a micro-controller, but I wanted to use something more powerful than your typical AVR. I supported the Micro Python kickstarter, but in the meantime I'm going to use a Teensy 3.1 to control this thing.

So, I fired up my CAD package, and came up with the model below. It uses treads from a Lego Technic set, but everything else is 3D printed.

Now, a week later, I have this:

The gear motors are placeholders for the real ones, which I've ordered, along with the optical encoders they support. You can see in the image below that they mount nicely using 1.6mm machine screws. This picture also gives you an idea of the scale - the robot will be 102mm long, 91mm wide, and 50mm high.

Shown below are some of the parts I'm using, including a dual-motor h-bridge, and a bunch of tiny connectors.

The robot will have 3 Sharp analog IR sensors, one on each side, and one in front. It will have, in addition to the Teensy 3.1 processor mentioned above, a 9 axis IMU, and a bluetooth module. The bluetooth module will allow me to write a simple app on my Android phone (Nexus 5) to control and get feedback from the robot. By "control", I really mean stuff like choosing a mission to run, since this robot (like all my others) will be fully autonomous. The robot also has optical encoders on each motor, with 500 counts per revolution of the drive wheel. That, along with full PWM control of the motors, will allow me to use a proper PID solution for control.

The motor driver board also provides analog feedback to the current draw of the motors, so I'll be able to detect if/when the motors are stalled.

The robot will use a pair of tiny 250 mAh lipo batteries in series.

At some point in the future I want to add a very small camera to this robot, and start playing with some very simple visual processing, like blob tracking and fiducial recognition.

Speaking of Roz, I managed to get him walking quite nicely at the conference using the NUKE engine running in Python on the Beaglebone Black. I didn't get any video, but I'll get some this week and post it here.