Was able to get rid of the rats nest on the breadboard

I can't really say anything for my soldering skills (I wouldn't pass this for quality control), but the results look a lot better. I really like the Parallax Board of Education for prototyping.  However, having all the wires loose like this really bothers me.  I was also having problems with connectors popping loose.  Now I have a simplified place to plug in my sensors and serial connections onto the Arduino and can focus on my interface to the RPi.



Sorry for the fuzziness of the photos, it looks like the iPhone 5 didn't get them too sharp and I was using a PicFrame app to couple three photos together.  Anyway you can get a sense of what was accomplished.  I haven't done any soldering for probably 15 years, so I am a little rusty. 

After I powered up the boards (smoke test), I did manage to wipe out the IR distance sensor.  Fortunately, the IR distance sensor was not that expensive.  It appears that the IR distance sensor was drawing too much current.  I also changed back to the Pololu Mini-Maestro but I could not get it to receive commands.  It looks like I have a power issue here which needs to be resolved before I go on.  I am not sure if I need to add a 5volt regulator on the board to get power from the Vin or not.  Have to think about that one.

Working on controlling the SSC32 from the Raspberry Pi

In light of the problems that I was having with reading the SSC32 pwm values from the Arduino, I thought that I might try and do the same via a serial interface to the RPi.  That is where I ran into difficulty, mostly because I was rather busy this weekend with other things.  I am trying to set up a serial terminal to communicate via a USB to RS232 interface cable to the SSC32 servo controller.  I first tried Screen but couldn't figure out how to get it to work, then I tried minicom.  I guess that I am just going to have to read up on these two programs in order to figure out the baud rate settings and commands.  I will probably try to do the same types of commands via a connection to my laptop.  But, I want to get it working on the RPi so that I can at least say it is part of the solution.  Remember, controlling the SSC32 and Mini-Maestro to move servos was not a problem, finding out the current pwm for a given servo was.

Got a new sensor in! A Sensor Stick.

I received a new sensor in the mail last week from China.  I ordered it online from Amazon at 10DOF (L3G4200D+ADXL345+HMC5883L+BMP085) Sensor Stick Breakout- for MWC/KK/ACM. As you can see from this photo, it is pretty small.  I wanted to get a gyro and accelerometer to use for an experiment that I was thinking about for the future and saw this online.


The description on the Amazon website says:

"This 10DOF sensor breakout is a very small sensor board with 10 degrees of freedom. It includes the ADXL345 accelerometer, HMC5883L magnetometer, BMP085,and the L3G4200D gyro. This break has a simple I2C interface and a mounting hole for fixing to your multi-project. just have a fund with it.

• The ADXL345 is a small, thin, ultralow power, 3-axis accelerometer with high resolution (13-bit) measurement at up to ±16 g. Digital output data is formatted as 16 bit twos complement and is accessible through either a SPI (3- or 4-wire) or I2C digital interface. The ADXL345 is well suited for mobile device applications. It measures the static acceleration of gravity in tilt-sensing applications, as well as dynamic acceleration resulting from motion or shock.
• The Honeywell HMC5883L is a surface-mount, multi-chip module designed for low-field magnetic sensing with a digital interface for applications such as low-cost compassing and magnetometry. The HMC5883L includes our state-of-the-art, high-resolution HMC118X series magneto-resistive sensors plus an ASIC containing amplification, automatic degaussing strap drivers, offset cancellation, and a 12-bit ADC that enables 1° to 2° compass heading accuracy.
• The BMP085 is a high-precision, ultra-low power barometric pressure sensor for use in advanced mobile applications. It offers superior performance with an absolute accuracy of down to 0.03 hPa and using very low power consumption down to 3 µA.The BMP085 comes in an ultra-thin, robust 8-pin ceramic lead-less chip carrier (LCC) package, designed to be connected directly to a micro-controller of a mobile device via the I²C bus.
• The L3G4200D is a 3 axis gyroscope, providing you with very high resolution (16 bit) measurements at up to 2000 degrees per second (dps). The gyroscope measures how much the device is rotating around all three axis, the range is user selectable and so can be adjusted to suit your application."

Obviously, I should be able to have fun with this.  One item that I did note was that the BMP085 is capable of outputting temperature readings along with the Barometric Pressure.  The barometric pressure readings give you a sense of altitude.  The sensor stick is apparently for use in small RC plane or helo type applications.  I plan on using most of the sensors for on the ground operation.  The sensor will give me the ability to have a sensor to work out a balance bot.  Woot!

Turns out it might not be the Pololu Mini-Maestro after all

I did a conversion last night on the test setup.  I removed the pan/tilt servo unit and the Maestro.  In place of the Maestro, I put the Lynxmotion SSC32.  I had to make one small adjustment to the input by switching the 4 wire connection to the Maestro in favor of a 3 wire connection to the SSC32.  I then made a copy of the current sketch that I was working and started changing out the code for the Maestro.  I decided that I would use the excellent SSC32 library from Martin Peris (http://blog.martinperis.com/2011/05/libssc32-arduino-ssc32.html), well actually a modification made found at http://dl.dropbox.com/u/50461514/LibSSC32Soft.zip which uses the SoftwareSerial library.  One function that I like about the library is the ability to "gang" a number of servo instructions together so that they all execute at the same time.  The equivalent command on the Maestro is the Set Multiple Targets command, but doesn't account for a difference in speed of execution.  Same but different - don't know if I will need that in the future but I am thinking of adding a Robotic Arm which will have several servos to contend with.  In either case, I need to have more than one servo going at the same time for the sweeps.

In the process of making modifications and testing out the code, the SSC32 started exhibiting the same failure to read that the Maestro did.  I was a little puzzled until I started reading up on the NewSoftSerial documentation at arduiniana.org.  It turns out that when you have more than one software serial connection that reads, you have to let the library know to switch objects in the code.  So now I am exploring how to do precisely that.

Command Testing for Serial Interface to Arduino

Ok, I have started implementing and testing the serial interface to the Arduino.  So far, I have coded the following sequences:

(1) 1/1/pinNumber/analogRate - to write an analog rate to a specific pin
(2) 1/2/pinNumber/digitalState - to write a digital state to a specific pin
(3) 2/1/pinNumber - to read an analog value from a specific pin (via serial)
(4) 2/2/pinNumber - to read the digital state from a specific pin (via serial)
(5) 3/1/servoPin - to read the current pose of a servo from a specific pin (not active)
(6) 3/2/servoPin/servoPose - to write a pose to a servo on a specific pin (not active)
(7) 3/3/servoPin - to detach a servo on a specific pin (not active)
(8) 3/4/servoNumber - to read the pose on a specific servo channel on the maestro
(9) 3/5/servoNumber/servoPWM - to set the pwm pose on a specific servo channel on the maestro
(10) 4/1/lowSweepIR/highSweepIR/speedSweepIR -

At first I had some problems trying to get servos to react.  I noticed that the servos were not zeroing at the beginning of the loop.  It turns out that my connection to the mini-maestro was not working.  After re-seating the connection everything started working correctly.

First test was the 3/5/servoNumber/servoPWM - worked correctly on two different servos (0 - for the Ultrasonic distance sensor, 6 - for the IR distance sensor).  I added some instrumentation via the LCD Panel and was able to see what the command was being interpreted as.  Servos moved, although there was a delay (I do have a one second feed in there).

Second test was to get the 3/4/servoNumber to work - although I could get some return values, they were not what I was expecting.  Need to do a little more homework on return values from the maestro and how I am able to read that through a serial interface.  I am getting absolutely nothing back from the Mini-Maestro.  I am even using code that I know works with the device (according to websites that have the listings).

Update: Am I up against a hardware problem?  If so, what is the least expensive way of implementing what I want.  Should I go back to the SSC-32?  The resolution in the analog domain was not that great, however, I am no longer using the Maestro to read the values from the IR or Ultrasonic distance sensors.

Distance sensor data gathering

So I was able to start gathering sensor data last night.  I wanted to start gathering information on the two distance sensors in order to be able to calibrate the system.  I have enough errors propagating around, I just wanted to understand a little more about the IR and Ultrasonic Distance Sensors themselves and how they behave and how well they measure distance.
In the picture below, you can see the IR distance sensor (GP2D12).  I was able to modify the Arduino code to give me values output on the LCD display.  My measurements were from the front of the sensor housing, that means that I will need to add the offset from the front of the sensor housing to the center of the servo rotation point to get an accurate reading on the measurements.

For the ultrasonic distance sensor (HC-SR04) the measurements will be the same.  I will measure from the front of the sensor housing to the target and will add the distance from the front of the sensor housing to the center of the servo rotation point.

Wires: now that I have everything hooked up on the Lexan plate, the wire jumble on the top of the Arduino breadboard is pretty much a mess.  I am thinking of getting a proto board and putting headers on it in order to not have the jumble on top.  You can see what I mean by the picture below.

When I took the values from the IR distance sensor, I was surprised to notice how much the value changed with each sample.  The measurements are as follows:

Distance	Measure1	Measure2	Measure3
2	7.24	7.22	7.26
2.25	6.76	6.72	6.72
2.5	6.84	6.91	6.82
2.75	7.54	7.64	7.68
3	8.23	8.66	8.57
3.25	9.23	9.18	9.15
3.5	9.97	9.97	9.36
3.75	10.95	10.92	10.85
4	11.39	11.32	11.46
4.25	12.28	12.24	12.24
4.5	12.84	13.05	12.84
4.75	13.72	13.72	13.72
5	14.39	14.29	14.24
5.5	15.67	15.73	15.67
5.75	16.63	16.26	16.5
6	17.08	17.14	17.08
6.25	17.96	17.89	17.89
6.5	18.47	18.4	18.18
6.75	19.01	18.7	19.01
7	19.9	20.15	19.98
7.25	20.33	20.24	20.33
7.5	21.52	21.42	21.42
7.75	21.81	21.71	21.9
8	23.26	23.04	23.04
9	25.9	25.51	26.03
10	28.63	28.79	29.11
11	32.89	32.29	33.5
12	36.64	36.4	35.92
13	35.92	31.92	36.4
14	40.65	40.65	40.65

Even though I took three measurements at each distance, the values pretty much vary pretty wildly.  A simplified graph of these measurements are as follows:

Actually, I should probably try and swap the x and y axis.  The x axis is the distance and the y axis is the measured values.  True to the data sheet, values that approach around 2 inches from the front of the sensor will change up and values over about 12 inches seem to start varying wildly.  In between, from 2 to 12 inches, the values seem to be steady and are almost linear given the formula in the sampling routine.  The values that return from the Ultrasonic sensor seem to vary even more crazily (see video below).

What I am learning from this is that I might have to rethink how the robot will follow the wall with the sensor data that I am seeing.

Distance Calibration and Angle of Same

Ok, here are the current issues:

1. I have two distance sensors on the Lexan plate.  One is a GP2D12 ir distance sensor that is supposed to measure some short range distances.  The other is a HC-SR04 ultrasonic distance sensor that measures somewhat larger distances.  Each of these distance sensors have non-linearity in the values they return.

2. Each of the distance sensors are mounted on servos on either side of the Lexan plate, meaning that the center of rotation is off center from the iRobot Create.

3. When the servos were mounted, I noticed that they were not completely perpendicular to the Lexan plate, nor is the Lexan plate oriented in a perpendicular manner when mounted to the iRobot Create.  That means that the angle of rotation needs to be adjusted.  In addition, the Lexan plate is somewhat offset from the center of the iRobot Create and may have a rotation effect.

4. There is an area on the plate where each of the distance sensors can rotate to and an area where they cannot, a sector of a circle if you will.  There will need to be adjustments to the sweep for each of the distance sensors so that the values they return will be acceptable.

5. Servos have issues in that there are discrete steps that they make rather than a continuous movement.  Also, there needs to be a correlation between the pwm value and the angle of rotation for the servos, which may be different in each servo.

The above issues make it difficult to relate the measured values with what is really out there.  This post is an attempt to define those issues and point to a solution.  The overall requirement is to have measurements be absolute to a specific point, in this case the centroid of the iRobot Create.  In order to do this I will have to deal with a number of coordinate systems.  To simplify everything, I am going to assume an XY plane (i.e., no Z axis involved here), however I will retain XYZ coordinates for purposes of being able to add them in later.  In this case translation is only in the XY plane, rotation is only about the Z axis, and the Z value is always 0.  Note that I will assume no scaling.  I will use matrix algebra to translate everything into iRobot Create coordinates (assuming that 0,0 is at the center of the Create).  So when I take a measurement of a point, it can be translated into the iRobot Create coordinates.  So to make it easier we have rotation around the Z axis at an angle psi with translation in the X (Tx) and Y (Ty).  Note that normally the translation in Z (Tz) would be zero.

Notice that if there is no rotation, i.e. psi is zero, then cos psi is 1.0 and sin psi is 0.0 which is just a standard identity matrix with the translation parameters imposed. Where to begin:

a. Assume center of Lexan plate is the Lexan plate origin.  The centroid of the plate should be an easy calculation, assume normal XY coordinates - measurements should be consistent (i.e., in inches).

b. Assume center of servo rotation is the servo origin.  Distance measurements from each distance sensor should be to the servo origin.  This simplifies the remaining transformations.

c. Servo -> Lexan coordinates: translate servo origin to Lexan center, rotate about Lexan center to compensate for Servo angle offset, scaling values should be equal to one (no scaling).  It should be easy to measure the servo origins in relation to the plate and figure out the translation values.  The servo angle offset may be more difficult, in the initial for simplification we can assume 0 degrees.

d. Lexan -> Create coordinates: translate Lexan origin to iRobot Create origin to compensate for plate offset, rotate about iRobot Create origin to compensate for plate rotation offset, scaling values should be equal to one (no scaling).

e. Create -> World coordinates: translate Create origin to World origin, rotate about World origin to get final World coordinates correct. No scaling, probably set the first matrix to an identity matrix for no effect.

Following the normal convention for such things, the final form of the equation is:

Next Move - Get Arduino SW Working

Connections are in place and now I can settle down to figuring out the software in the Arduino, the breadboard connections for same, and the interface software from the RPi.  I still have a number of interfaces that need to be tested:

1. the Ultrasonic Distance sensor needs to be wired up through the breadboard and the interface software needs to be written for the Arduino
2. the IR Distance sensor interface software needs to be written for the Arduino
3. the interface software for the two distance sensor servos needs to be written for the Arduino
4. the interface software for the two camera servos needs to be written for the Arduino
5. a control protocol, including response, needs to be thought up between the RPi and the Arduino and coded on both sides - ultimately this will be used by several Facades in the RPi software
6. a control protocol, including response, needs to be thought up between the RPi and the iRobot Create and coded in the RPi
7. afterwards I can concentrate on more higher level software, including the blackboard.

The connection diagram has changed

Now that I have come to the conclusion that I can move a lot of the hardware control down to the Arduino, I have redone the Test Setup connection diagram.

This diagram now shows the two ways that I have of controlling the iCreate, either through the Arduino or via a USB serial line.  In addition, I have added the IR and Ultrasonic Distance Sensors and their servos.  I changed out the SSC-32 for the Maestro, since that seems to be a better bet.  I have also added a temporary place holder for a Joystick/Button shield connected to an Arduino.  The purpose for this connection is to be able to use a Joystick controller to control movement and camera remotely, not something I want to have in the final model.

Was able to Setup Full Connection

Now that I have settled in on what the interfaces should be, I took the time to mount the Arduino and the Pololu Micro-Maestro onto the Lexan piece.  I did take advantage of the fact that the Lexan is not conductive, and just screwed the Maestro down onto the plastic without any kind of standoffs.




A close up of the connections is shown in the following picture.

I will say that I did at first have problems with the setup.  After I got everything mounted I tried out the Arduino test program that I had written, and I could not get it to work.  I started removing all kinds of wires and eventually got everything down to just the interface to the LCD panel and I got it to work.  What I did not realize was that when I turned on the power to the servos, I failed to turn on the master switch on the power platform.  That is why the servos would not operate, they did not have any voltage because I had removed the voltage jumper on the Maestro.  Once I figured that problem out I was able to get both the one servo and the LCD to respond.  Maybe I need a checklist.

Just got a new Gertboard

I just received a new Gertboard for the RPi. It was home when I arrived from my trip to Florida. When I opened it up, I was expecting that there would be a ribbon cable amongst the items in the box. However, as I started looking through the user manual, it became apparent that I was wrong.




The Gertboard has a different connection when used with the RPi.




The Gertboard has a GPIO connector, but is turned away from the RPi. The kit does have standoffs, the assumption is that the combination sits on the table. I will now Need to determine if I can actually put a ribbon cable on the Girtboard and connect it to the RPi. The combination takes up a lot of real estate and is really not functional for use with the Robot HW that I am building up. I only have so much room on the piece of Lexan. What this will probably force me to do is use the Gertboard to make a circuit and then duplicate it on a breadboard. Then again, maybe I will use the Gertboard for other things.

Did some more setup

I spent a little time and finally got the servos and the new RPi mounted in the Lexan.


After looking at what I was able to do, it turns out that my servos are a little misaligned.  That means that I am going to have to calibrate the camera, all angles, the sweep motion, and other stuff in order to be accurate in any experiment that I might be doing.

Strange things you find out about

When I was at work last week, I talked to one of the other engineers and found out a few things about the Arduino, another single board computer. I found out that there is an IDE that you can use to compile and load new software into the Arduino. What I later found out was that the same IDE could be used to compile and load programs into the similar chip on the Gertboard. So I thought to myself why not start exploring the Arduino and find out some more about it, maybe I can use it in some of my experiments. Today I found out that you can put the Arduino IDE on the RPi as well as connect the Arduino and RPi together. So it looks like I will simplify my life somewhat and offload some of the tasking for watching the servos and distance sensors onto the Arduino. Yep, that's right, I went out and purchased one to use in my experimenters box.





That's a Ethernet shield on top, because I wasn't sure how I was going to get access to the Arduino from the RPi. Now we know.

Thinking about a distance sensor experiment

Last night I received another distance sensor, Ultrasonic Module HC-SR04 Distance Sensor For Arduino, from Amazon.  This is a sensor that is a little more long distance than the IR sensor that I have which has a range of 1-12 inches.  Using the two sensors, I now have a short distance and long distance resolution.

I was thinking that I might use the sensors in an experiment on top of the Create that would allow me to figure out the best way to use them.  I would like to design a wall follower.  Both of the sensors could be used to sweep back and forth, gathering distance/angle data and then take that data to build a model workup of the hallway or room that the Create was in.  From that information you could develop a driving routine that would day allow you to follow a wall within 5 inches.  Other parts of the routine would be able to react when something was placed in the way of the Create.  It would have to make a decision to go around and what would be the best way to do that.  I am thinking that the blackboard idea that I have proposed before would be the best option for doing this.  My use of the Blackboard would require me to have an overall computational strategy.  This is something that would need to be worked on.

I am still out on whether I should interface to an Arduino to control the sweeping sensors however.  That seems to be a better way to accomplish the goal.  Both of these sensors interface directly with the Arduino, whereas I would have to really think about how I would do this in the RPi.  I do have more than one RPi in order to accomplish multiple computer type tasks, but a control processor may be more useful this time around.  I could then concentrate on using the RPi to do the decision tasks.

Have had difficulty in getting interface to Pololu Maestro Servo controller

I have tried a whole bunch of things, trying to get the Pololu Maestro Servo controller to work with the RPi.  Although I was successful at loading the linux loads from the Pololu site, it turns out that it needs an i386 architecture which does not help me.  So what do I do now?  I have been searching all over the net looking for someone who has successfully used the RPi with this controller.  I may have to go back to my SSC-32 to get it to work.  I would really like to use the Maestro because the analog input has a lot more bits to play with.  Time will tell.

Update: I did manage to load the Pololu Maestro controller onto my laptop yesterday and this morning I was able to get the servos to move and read the output from the distance sensor.  So I at least know that the board works on a Windows 7 platform.  I just need to do the same thing via the RPi.

Built up the pan-tilt camera unit and distance sensor sweep

It's Saturday and I was given the chance to,work on some Robotic elements that I have been neglecting. I took about an hour to make up
a Pan/Tilt unit with some spare servos that I had laying around. I was also able to make up a sensor sweep with an additional servo. The two units look like this (sorry for the poor picture quality, crappy camera on the iPad):





The Pan/Tilt unit on the left has a servo mounted vertically for Pan and a servo mounted horizontally for Tilt. The webcam is a Microsoft Lifecam with a IDE field of view and a built in microphone. Here is a close up.





The servo mounts are some that I had left over from two years ago when I was diddling with Robotics. The sweep unit uses one servo mounted vertically.





The L shaped bracket has an IR distance sensor mounted on it. I am hoping to interface these two units to a Palolu Maestro servo controller. I did see where someone had written a Python library to control the Maestro using ROS. So now you know what direction that I am headed.

Put in order for Gertboard

I put in an order yesterday for an assembled Gertboard, an additional RPi, a cable breakout from Adafruit, and a wire connector kit.  I decided on getting the Gertboard after looking through the user manual.  I am convinced that it gives a lot more control over what the RPi can do in terms of interfacing that what I have available with the PiFace.  However, right now I will deal with the PiFace and report on the pros and cons of making my Robotic interface.

The key detail that told me this would be a good buy was the fact that the Gertboard has a plug panel arrangement.  You only patch in the items that you wish to use.  There are different groupings of capability on the board, but you only have to interface to some of them, and arrange them in any order you wish.  Good design for experimentation!

Trying to make sense of an iRobot Create setup

Well, I have been trying to figure out how to wire the RPi / PiFace / iRobot Create (iCreate) / SSC-32 so that I can do what I want to on the iCreate both on the bench and mounted on the iCreate.  So far my test setup is as follows:

So far, what I haven't shown in this diagram is the connection wires between the iCreate DB25 connector and the PiFace.  I have decided that they will of necessity have to go through a protoboard.  The PiFace will also be connected to a distance sensor.  The actual control for movement will be done by serial connection (the iCreate USB to serial cable) to the iCreate body.  This stems from the fact that I have not figured out which pins are going to do what with the interface.  I can put this test setup together over the course of a few weeks. I do show a temporary connection to the RPi via Ethernet as this will serve to be the network connection to the RPi while it is on the bench.  While the test setup is on the bench, the MonoPrice Battery power will be supplied by a dual USB power supply and the iCreate Battery power will be supplied by a 6 volt power supply.

So what am I able to do with this setup?  I am able to build up to a final configuration over time.  The key elements are:
(1) implement a connection strategy between the RPi and some other controller over WiFi or Ethernet
(2) control of the pan/tilt servos via the SSC-32
(3) stream the camera to and through the RPi
(4) control the iCreate via a serial connection from the RPi
(5) interface a distance sensor to the RPi via the PiFace
(6) interface various digital pinouts on the iCreate DB25 connector via the PiFace/Protoboard
(7) Use either battery power or power supply to power up the equipment

I am hoping that I will be able to put together the test setup in a number of phases:

(1) System on bench / ethernet connection:
a. build up a Lexan plate with holes drilled for the iCreate body, mounting for the RPi, mounting for the SSC-32, mounting for hub / batteries, and mounting for a pan/tilt unit for the camera.
b. mount plate on the wood platform via standoffs with the rest screwed into the plate.
c. build up pan/tilt unit, interface pan/tilt to SSC-32, test with RPi.
d. connect camera into system, test with RPi
e. connect RPi over the network via ethernet, stream video over ethernet
(2) System mounted on iCreate / power from bench(3) System mounted on iCreate, all connections independent of bench