Mo Than A Po Boe-Bot
TinkersALot
Posts: 535
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:
http://forums.parallax.com/showthread.php?t=125220
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.
(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:
http://forums.parallax.com/showthread.php?t=125220
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.
640 x 480 - 293K
640 x 480 - 280K
640 x 480 - 247K
640 x 480 - 252K
640 x 480 - 290K
640 x 480 - 330K
Comments
However, I was running this little feller today and after some time, I think I saw a stall in the sensor deck. I haven't had a chance yet to dig into it because today became a heavy-duty, honey-do, chore-mode day.
So, I'll have to study this code more and/or scope it out with debug statements to see if I can see any reason why the sensor deck cog would crash somehow (though I can't see why that would happen (yet anyhow)) or if the system is having a message queue stall.
I also don't think I have the "sensitivity" of the IR sensors quite right yet because I am getting periodic false triggers from the sensor deck (causing the platform to steer around obstacles that are not there. So, it looks like I do need to some more testing of the sensor deck module.
Once I get it all sorted out, I'll try to shoot some motion video of the unit doing its thing.
@Martin_H, I think the encoder/tread combination works well and if you can come up with the right hardware bits to pull it off. Based on experiences thus far, I'd recommend it as an improvement over "just treads." I do have issues with my implementation from time to time if I bump the screw holding the encoder in a way that causes it to get loosened (since it is a spare parts job, my screws are just a tad too short).
When that happens the encoders just "float" and are therefore not reliable while in that state. I haven't convinced myself to apply glues yet since tear downs are still part of this project. Other than this ham-handed issue, the concept works really well.
I'd say it works especially well with the "go for tick count" (based on encoder pulses) that I have in the program code. In my judgement, forward-going travel is very much straighter than it is without using the encoders. I haven't tried any specific courses (like do a square or a star) so I don't have any information on how accurate this solution is.
I'll have to add that kind of dead-reckoning tests to the to-do list, but there are still some potential for some as yet undiscovered flaws in the code for me to work on.
1. Corrected IR Ranging trigger values and treatment of the IR results - this was the cause of the false triggering
2. Corrected incorrect handling of queue locks - the error fixed here was the cause of the queue stalls
3. All motor driver directions (fore, back, left, right) now are encoder based -- was able to reduce the amount of code in the driver object by this
4. Object "start" calls are inside the cog message loop. This simple fix improved reliability of the sensor deck with regard to the servo pan-scanning servo.
With this update, the code is getting very near complete. I think I've just got to work out a couple more finer points of motor control and then it should be video time.
Hope some of the techniques discovered while I was developing this program code helps somebody out there.
1. First Attempt at a stall detector in the servo driver. This is accomplished by evaluating the count register on each pass through the driver loop. If the count is found to be the same as the last sample (no encoder pulses) then an internal counter is incremented. If the internal counter reaches a specified threshold, then this is evaluated as a stall and the motor driver routine will return.
2. Found and repaired a heinous error in the message queue management. YIKES! How did this stuff ever work?
3. Experimenting with asynchronous message acknowledgements (from the motor driver cog back to the sensor-deck cog) to try to head off "message storms" that can occur when the platform is still in motion while the sensor thresholds are already violated.
FULL SCHEMATICS (drawn using the propeller tool) in the pin-defs "header file". I have to admit that this feature of the propeller tool is very easy to work with once I broke the ice on it. Moreover, this seems like a nice way to more readily share program projects because the schematic is right inline with the program. Admittedly, I do not yet know the "upper end of practically for this feature or how for I'd be willing to go on the "complexity scale" for a schematic.
However, even with my first experience with this feature, it seems to me that the editor would really benefit from:
* Area selects (define a rectangular region to manipulate-- NOT whole lines) for copy and paste operations
* Improved "indent managment" for moving entire regions around.
* IF the editor does this already and I just didn't find out how that works, then I am willing to offer an immediate retraction and apology for this criticism.
This update also contains a fix for the stall detector code (found a copy paste error for stall detection counters).
Humanoido