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.

Lower Level Classes for Experiments

In looking at the overall structure of what I want to do with experiments and such, I have come up with the following list of lower level classes that need to be developed:

1. SSC-32 Facade - [HW interface] this will be a collection of routines that will be able to get to the execution points for the SSC-32 servo controller.  Specifics:
a. include routines to open / close the connection(s)
b. include routines to read analog and I/O for the digital aspects of the controller
c. include routines to set / read the current pulsewidth of the servo control. since the controls may be made through the Arduino, this facade needs to make sure of being able to proxy the connection to the SSC-32, and this might involve going through the network

2. Pololu Mini-Maestro Facade - [HW interface] this will be a collection of routines that will be able to get to the execution points for the Pololu Mini-Maestro (18) servo controller. Specifics:
a. include routines to open / close the connection(s)
b. include routines to read analog and I/O for the digital aspects of the controller
c. include routines to set / read the current pulsewidth of the servo control
d. since the controls may be made through the Arduino, this facade needs to make sure of being able to proxy the connection to the Pololu Mini-Maestro, and this might involve going through the network

3. Arduino Facade - [HW interface] this collection of routines will utilize the Firmata protocol initially and later will reflect a home grown protocol later on.  The purpose is to be able to access most of the functionality of the Arduino through this interface.
a. general interfacing topics for the Arduino is at http://playground.arduino.cc/Main/InterfacingWithHardware.
b. the Firmata information is at http://firmata.org/wiki/Main_Page.

4. Video Facade - [HW interface] this collection of routines will focus on gathering a video stream and/or information about the video including snapshots and setting webcam parameters.

5. Robot Link Facade - [HW interface] this will be a collection of routines that will be able to move data between various CPUs within the Robot and will include connections to external PCs.  The reasoning for having this Facade is to be able to grab sensor information from a remote source as necessary.

6. Ultrasound Distance Sensor Proxy - since I will not know in advance of where I will connect the Ultrasound sensor, this will utilize the underlying Facades to control and gather information re the sensor.  I want to include calibration routines, setting the servos, reading the sensor, starting/ending sweeps, etc.

7. IR Distance Sensor Proxy - since I will not know in advance of where I will connect the IR distance sensor, this will utilize the underlying Facades to control and gather information re the sensor.  I want to include calibration routines, setting the servos, reading the sensor, starting/ending sweeps, etc.

8. Camera Pan/Tilt Proxy - since I will not know in advance of where I will connect the pan and tilt servos, this will utilize the underlying Facades to control the servos.  I would like to include setting the position of the servos and reading where the servos are, along with calibration routines.

9. Video Stream Proxy - this will pretty much be an interface point to the video stream, no matter where the webcam(s) are placed.  This would include such things as streaming the video between CPUs within the Robot space.

10. Robot Arm Proxy - since I will not know in advance of where I will connect the robot arm servos, this will utilize the underlying Facades to control the servos.  I would like to include setting the position of the servos, getting feedback on other sensors (pressure), and reading the servo positions, along with calibration routines.

I think this is a list that will keep me busy for a while getting ready for the main routines to execute the Robot software.

May Have Found an In-Between Code for Arduino

I had an interesting question for one of the engineers this morning.  I asked him if he knew of any remote control for the Arduino in which a command could be sent to the Arduino for execution in lieu of programming the Arduino for a specific purpose.  Interestingly enough, I found the Firmata project (http://firmata.org/wiki/Main_Page).  This appears to be a protocol based upon the Midi control signals and is geared for micro-controllers of which the Arduino is one.  There is a load for the Arduino for the protocol server, and a test program to run from a side computer.  All software is available for both sides.  In looking through the protocol, it looks like it might do everything that I need it to do for experimentation purposes.  Obviously, I would program the Arduino to do specific tasks after I figure out what I need it to do.

The Strange Process You Go Through

It might appear to be a little weird that I have been concentrating on the hardware aspects of experiments prior to concentrating on the software aspects.  The reasoning is that:

1. I have something in mind that I want to do,
2. I visualize what it would take to do it,
3. Since I am not that familiar with the hardware devices, I order some that look interesting,
4. When I get the hardware in, I assemble it into an experiment package knowing that I will need to try out a few things prior to getting the final product,
5. Write out software for the experiments and choose the best course of action for the final product,
6. Design the software for the final product,
7. Changeout the hardware to accomodate the final product,
8. Code and test the software for the final product

I have more of an experimenter's mindset when it comes to these things.  I want to learn and the best way to learn is to try things out and come to some sort of a conclusion.  You not only get experience but it helps later when you are trying to design something else.

Opened up a repository at GitHub

In light of my wanting to get ambitious, I have added a repository at GitHub (https://github.com/linuxweenie/rpiexperiments).  I will have the link for this repository to the right of the blog and will be adding software as it becomes available.

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.