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 the Blackboard Issue

Over the last couple of days I have taken a hiatus from working on the Robot HW.  I am instead concentrating on the Blackboard implementation that I have in mind.  I have decided to wrap my design around a combination of the Blackboard, StructuredMatcher, and Command Processor design patterns.

The Command Processor design pattern, as described in POSA1 (Pattern Oriented Software Architecture, vol 1, Buschman, et al.), separates the request for a service from its execution.  The CommandProcessor component manages requests as separate objects, schedules their execution, and provides additional services.  The AbstractCommand component defines the interface of all command objects, as a minimum defining the procedure to execute a command.  In this way, individual commands can be treated as objects.  The derived command will encapsulate a function request.  In the implementation that I will be making, there are two multimaps in the CommandProcessor component.  The first one is a multimap containing a name and a pointer to an AbstractCommand.  This is the multimap illustrated on the following diagram.  The second is a multimap containing two names.  The first name is the list name and the second is the name of an abstract command contained in the first multimap.  This allows a grouping of the commands by a name.

What is missing from this design is a way to have a named list that has a prioritized listing, therefore the AbstractCommand will need to be modified to contain a priority and a strata level.  This will become more apparent as the blackboard pattern is introduced.

The Structured Matcher design pattern (from "Structured Matcher" by Eugene Wallingford, 1998) decomposes a complex decision into simpler decisions about relevant factors and then uses decisions about these factors to make the decision.  I will be using this design pattern to form the rule pattern portion of a knowledge source.  Notice that the Structured Matcher inherits from the AbstractCommand component and therefore is utilized within the Command Processor pattern.  The Structured Matcher consists of a directed, acyclic graph of simple matchers.  The Simple_Matcher component considers either the values of sub-decisions made by other simple matchers or the values of input data. A data parameter feeds into only one simple matcher.  The diagram below is a start on the design of this design pattern.  In the Structured_Matcher component there is a multimap containing a name and a pointer to a Simple_Matcher called root.  This allows the Structured_Matcher component to have a matcher list to work from.  The Simple_Matcher forms a composite design pattern with the Parameter component.  By doing this the structured matcher design pattern is composed of a list of hierarchically defined simple matchers.  One of the derived classes from the Simple_Matcher component will be a Top matcher, or top of the hierarchy. [Updated]

Finally, I will describe the Blackboard design pattern later.  I have succeeded in separating out the Domain and Control knowledge sources and I have almost completed the initial way that it will work.  However it is not complete as of this point.  I got a little bogged down in the control plan layout and how that interacts with the other design patterns.

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.

Located a library to use with HC-SR04

I was doing a search this morning and happened upon the site at http://code.google.com/p/arduino-new-ping/.  This appears to be a library with the ability to filter the HC-SR04 ultrasonic sensor.  It also appears that the author had many of the same problems that I encountered with the sensor and dealt with it with multiple pings, distance sensing, etc.  I will need some time to digest what it is capable of doing but maybe this is a better bet for a more stable read from the sensor.