REVISED CODE IS ATTACHED HERE NOW.
(Same updates are also at later post below).
This topic somewhat of a continuation of this other robotics thread
For some background, you may want to see:
The "physical layer" of the project is now "complete" (well until I decide to add something to the 14 still-open I/O pins on the propeller (I'm not counting I/O pins 28-31 in that count) so there is still "capacity" on this project for more "stuff". Perhaps some sound and blinking lights will be fun to add next.
The phsical layer of this project is summarized as follows:
* Boe-Bot chassis
* Boe-Bot encoders
* Boe-Bot tread kit
* Boe-Bot PING sensor kit
* SPIN-Studio (propeller-based) board
* SPIN-Studio Servo-I/O board. This is used as the interface for the Left and Right chassis servos, for the PING "panning scan servo", and finally for the PING itself
* A Radio Shack 9.6 Volt rechargeable battery (the SPIN Studio board runs with a 9 volt DC supply). As luck would have it, I had one of these from an old R/C car that was tossed aside by the kids.
* A front mounted "sensor deck" that has "left and right" contact whiskers, left and right facing IR distance sensors. The interface circuitry for the encoders is also on this sensor deck. There are 5 signal lines for the "left" side of the sensor deck and 5 more for the "right" side of the sensor deck.
* Two each of SPIN Studio prototype boards (filled with SIP connecters so that these can act as breadboards). One of these provides interface to the "left side signals" from the sensor deck. The other provides interface to the "right side signals" from the sensor deck.
I elected to use 90-degree header-connectors between the SPIN Studio interface cards. For a robotic applicaiton like this, this simple improvement keeps the interface cards out of the "damage path" more than if they are mounted in the standard "out-rigger" style that is the standard way that SPIN Studio IO boards are oriented.
With this project being Propeller based, it also serves as an experimental platform for my stingray (and even perhaps to some degree the Scribbler2 when it comes out).
I have attached the current version of program code running in this platform. I have elected to use a multi-cog, message passing queue approach as the basic program architecture.
The main cog starts up two addtional cogs. One of these cogs is dedicated to motor control and reading the encoder output for each of the drive motors. The next cog is dedicated to monitoring the whisker, IR, and PING sensors. Once the main cog has started the motor-control and sensor-deck cogs, it sits in a message dispatch loop where it will forward any message from the sensor-deck cog to the motor-control cog. As a future enhancement, the main cog could pre-process the messages received prior to forwarding them. But, for now, the main cog simply forwards any message received.
The sensor deck runs in one of 2 modes. One mode is under message control. The other mode is in "Free running mode".
When a message is read from the message queue, the sensor-deck is operating under message control mode. When the sensor-deck cog receives a command (via its message queue) it will measure the specific sensor requested and will reply with an outbound message regarding the results of the sensor check.
When no message is read from the message queue, the sensor-deck cog will "free run" which means it will continually scan the sensor deck. If any sensor reports a "contact" it will eject a message to the main cog indicating the type of sensor that was triggered and "what side" (Left or Right) the trigger occurred on.
"Contact messages" from the sensor-deck-cog are intended to interrupt the "free running mode" of the motor controller cog. The motor-control cog also runs in a message loop. If it receives a "contact message" then it will steer the chassis motors in direct response to that message. If no message is received via the motor-controller message queue, then it will free run which just moves the robot forward.
Note, that since I am running Beau's servo controller there is another cog doing background work for the PING servo, so in total, this implementation utilizes 4 of 8 cogs; so there is lots of additional computational power not yet used by the current architecture.
Other key points to look for in this version of the software are:
* "Global header File" I figured out how to create a "global header" in SPIN that has really nothing but contants defined in it. I use this so that I can locate ALL PIN DEFINITIONS in a SINGLE FILE that is common to the entire program. The trick to doing this was to put a "throw away method" in the file (just to make the SPIN compiler "happy").
* Inter-cog messages
* The inter-cog message buffers are synchronized with locks in order to provide "thread safe" read/write access to the message queue buffers. The locks are associated with ranges of the message buffer so that multiple messages (bound for different cogs) can be simultaneously written-to/read-from the message buffer.
* Counters are utilized in the motor-control cog. When the chassis is moving forward, the counters are loaded with a "go forward tick count" and then the encoder associated with each drive motor is monitored against this "go forward tick count". This scheme is meant to account for differences in the Left and Right servo so that the chassis is driven in a straight line when going forward.
* Duty Cycle counters are used for the IR sensors (as is described in the Propeller documentation) to provide for more accurate distance ranging of the IR sensors. This is the least tested of the sensors on this project, and I'm not sure yet I have the "danger range" correctly defined.