Co-processor scheme for Toddler - any suggestions
LoopyByteloose
Posts: 12,537
I have a Toddler that has the following:
1.· Twinkle Toes
2.· Regular on board IR that may read edges, dropoffs or obstacles at about 24 inches
3.· IR on the toes that reads directly·down for dropoffs and edges
4.· Sonar mounted on a servo [noparse][[/noparse]at the top of it all] that may seek a pathway by searching in a 120-180 degree sweep.
One of the difficulties with the Toddler is that real time applications seem to slow down its locomotion.· After fooling around with it, I have decided that the Sonar and servo should be on a separate co-processer and I have a BS2p-24 to provide for it.
What I want to do is to try to use that co-processer to evaluate the most likely open pathway by using the sonar.
I don't expect the co-processor to handle drop offs or edges, mainly looking and planning ahead while the Toddler is using its main board to walk.
Periodically, the co-processor would feed corrective movements into the main board [noparse][[/noparse]let's say a series of eight steps codes at left, right, or forward]
As I envision this, I can either interface by using two pins for the left, right, or forward with maybe a third to acknowlege -OR- I can try to manage a more formal serial interface.· Personally, I like the first scheme as it seems like less overhead and more intuitive.
So, having·said all that and being curently immersed in programing the co-processor - does anyone have suggestions.
I can relocate any and all of the IR to the co-processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
1.· Twinkle Toes
2.· Regular on board IR that may read edges, dropoffs or obstacles at about 24 inches
3.· IR on the toes that reads directly·down for dropoffs and edges
4.· Sonar mounted on a servo [noparse][[/noparse]at the top of it all] that may seek a pathway by searching in a 120-180 degree sweep.
One of the difficulties with the Toddler is that real time applications seem to slow down its locomotion.· After fooling around with it, I have decided that the Sonar and servo should be on a separate co-processer and I have a BS2p-24 to provide for it.
What I want to do is to try to use that co-processer to evaluate the most likely open pathway by using the sonar.
I don't expect the co-processor to handle drop offs or edges, mainly looking and planning ahead while the Toddler is using its main board to walk.
Periodically, the co-processor would feed corrective movements into the main board [noparse][[/noparse]let's say a series of eight steps codes at left, right, or forward]
As I envision this, I can either interface by using two pins for the left, right, or forward with maybe a third to acknowlege -OR- I can try to manage a more formal serial interface.· Personally, I like the first scheme as it seems like less overhead and more intuitive.
So, having·said all that and being curently immersed in programing the co-processor - does anyone have suggestions.
I can relocate any and all of the IR to the co-processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
Comments
You should probably use the SERIN/SEROUT commands for that.
Check the pbasic 2.5 help splat for information on those commands. -bugg
That's a useful idea. Programming the Toddler really starts to show the limitations of any single-threaded device like a BASIC Stamp. First, I assume you already know about Harry Lewis' co-processor for the Toddler:
http://www.bluebelldesign.com/
Harry's approach uses a SEROUT from the BASIC Stamp with the different parameters (start, end, rate, ramp) for moving the servo from one position to another. He provides some sample source code.·His co-processor goes a bit overboard by managing all sensors and inputs, essentially running the robot. Maybe he'll jump in to clarify, but I'd take a slightly different approach.
I would use a co-processor on a Toddler strictly for servo management - nothing else. The reading from tables, pulsing of servos, EEPROM pointers, etc. alone are enough of a challenge, so I'd use your second Stamp just for this purpose. I suggest leaving all sensor management on the other BS2.
I'd also start with a simplistic approach. Allow the servo BS2 to only do serial between complete movements, not between individual servo pulses. This eliminates management of the EEPROM pointer [noparse][[/noparse]to take a step back 80% through a movement] It might be that when you decide to make it really practical and you want to send and receive serial between every servo pulse both Stamps will be innundated with serial communication. Maybe you could device a 4-bit parallel interface instead for speed/simplicity? Just a thought. . .
Your proposal to send a series of steps (such as eight of them) is a fine start. You already know that this will become a problem for frequent changes in direction or pace, but if you're running across the room maybe this doesn't matter. Not sure how big those rooms are in Taiwan.
One other thought is that the SX could·make a great servo co-processor for the Toddler. Since we've released SX/B it·got a lot easier to program that chip. Maybe Jon Williams will even incorporate a serial servo controller into the help file for us.
Another final thought is to use the Parallax Servo·Controller. Works, done, efficient, etc.
I'm working on a micro-Toddler right now. Picture is below. This one will use an SX for servo management, without a doubt. Programming the Toddler is one aspect of that robot that always burned me to pieces. Following those EEPROM pointers around is really tough.
Sincerely,
Ken Gracey
Parallax, Inc.
Post Edited (Ken Gracey (Parallax)) : 1/3/2005 5:00:41 AM GMT
I am aware of the Bluebell co-processor, but it seems that I could use the original board for locomotion, provide the faster BS2p for more complex, sensor management and focus primarily on improving my PBASIC skills rather than learning how to manage the Bluebell's code scheme. If I were building from scratch, I would definetly consider beginning with the Bluebell, then adding the BS2p, but it would be a completely different learning route.
I am still having trouble grasping the need to use SERIN, SEROUT when I might use a two bit code (01=left, 10=right, 11=forward, 00=no input) to poll the sensor results. the difference seems to be that my way will use maybe 3 pins [noparse][[/noparse]two for code/one for hand-shaking] versus the serial using 2 while I don't have to use a lot of space to encode and decode the serial port. Of course I may be wrong.
I have some SX-28s, but am not ready to try to integrated them as I am not up to speed on the Assembly programing.
The twinkle toes and the edge sensors on the toes are likely to remain with the orginal locomotion (along with the Mesmic if I keep it) as all of these need to respond immediately to hazards that will cause a fall or collision.
Then the second processor can offer navigation more as a long-term suggestion.
The idea is to get the Toddler to wander while maintaining its ability to walk. And, I really need to get my PBASIC up to snuff.
The micro-toddler is very neat but I fear that it would be too small for my needs. I moved the batteries to the legs and added some [noparse][[/noparse]two packs of 3 AAx] so that I could get more power for add-ons and to allow the eventual wandering demonstration to continue over a longer period of time. Eventually, I have a R/C interface that can be installed or I might you IR remote control [noparse][[/noparse]the BS2p will handle IR remote control where the others will not].
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
I'm probably going to use that system, but you need to connect both grounds together.
-bugg
I also read somewhere that all the grounds to motors and devices that are unrelated to the digital side of a robot should be collected together and fed into one and only one ground connection on the digital side.
It seems that you may get some complications otherwise due to multiple pathways and motor noises.
By the way, I did go to Blue Bell and took another look in the Toddler manual.
I can't used their product because they don't ship to Asia, I don't use PayPal (as I get faudulent PayPal notices daily in my email),··and -- though it is a really neat product -- it uses 4 pins and is quite a bit of a technical overcapacity (8 servos, some analog inputs, etc.) that I fear will just keep me away from my PBASIC and off into another high level code scheme.
I have been trying to sort out my architecture and it looks like I wil have to eliminate the original IR from the BS2 coprocessor. It is more likely to work well with the sonar on maintaining the 'far view'. Sadly, that mean removing it from its well place mounts and creating another support for it.·
Since the toes have their bumpers for actual collison and local IR pointed directly down for drop off detection, those paired devices will keep the Toddler from walking into a hole or trying to walk through a low profile obstacle. That seems like quite enough.· Though the memsic will also stay to allow the Toddler to adjust for odd terrain (I may even have in work both axises eventually).
But, I think I do need to add a REVERSE motion to the data. I think that I may need the Toddler to REVERSE and TURN when it identifies a hole or drop off. Otherwise, it may just get hung up in close proximity to such trouble and eventually get caught.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
Post Edited (Kramer) : 1/4/2005 3:20:02 PM GMT
backup control. -bugg
I'm from Blue Bell Design Inc. I would like to thank Ken for·mentioning our·company·and clear up some confusion regarding our Co-Processor and maybe some add something toward building a more fully featured Toddler.
1. I have no problem shipping to Asia. The site only shows PayPal for funds transfer but there are other ways so please email me off-forum if you are interested.
2. Our Co-Processor can control IR "vision" and has inputs for 2 bumpers but the actual Toddler walking control is in the Stamp. You can choose to use these features or ignore them and use the Stamp for all the sensor inputs. We do have a mode to control a rolling robot like a BoE-Bot but it doesn't apply for a walker. In the case of programming for a Toddler, just don't bother to turn it on and you can ignore it.
3. What do we offer that is useful for the Toddler?
·· a. Servo controller with ramping. As Ken wrote, it means you just tell the servo where to go (2 bytes) and it goes there at a rate you previously specified. That frees up the bulk of the real time processing load on the BS2. There is no real "programming scheme". Just send a serial command that tells what you want, move a servo, read A/D, etc. and it does it.·All·actual programming is in PBASIC on the Stamp. You can use a third servo channel to painlessly scan the SONAR.
·· b. A/D inputs are nice for the Sharp IR distance sensors that·put out an·analog voltage. They might also be better than SONAR for long range navigation planning because they are more pinpont than SONAR.
·· c. Since you have so many extra IR detectors, you could use the set built in to·our Add-On kit and save some Stamp processing and inputs.
·· d. The Add-On kit attaches easily to the Toddler.·The mounting holes were designed to match up with those in the Toddler PCB.
·· e.·The biggest feature we have are the timers. They allow the Stamp program to go off and do whatever sensing you want to do and yet be able to easily know when the servos are done moving. Tell the Co-Processor how long the servos will take (or how long you want to walk in a certain direction or..) and a single signal will alert to the timeout of up to 8 independant times. This allows the Stamp to truly "multi-task" and really multiplies its compute power. This would be great for the SONAR scanner servo.
·· f. Our serial I/O is accomplished through a hardware UART. That means the Co-Processor is always ready to accept serial data. And it never tries to send anything to the Stamp unless in immediate response to a command so·the·message is never lost. That can be an issue with 2 Stamps talking serial while independently processing. If one Stamp wants to send a message to the other, the receiving Stamp has to be expecting it or it can get missed.
If you would like more explanation and programming examples, see Appendix C of the Toddler manual or our website www.bluebelldesign.com
That all being said, if you want to use the 2p24 you already have, I would recommend using one processor to pre-process the sensor info and then have some parallel signals to give the results to the motor control processor. For example, all your drop off sensors could be considered a single bumper on each side. Instead of just using the "Toddler Toes" as inputs, use the 2p24 to add the downlooker functions to the Toes and provide a one "backup because bumped" signal for each side to the motor control BS2. Trying to do serial between the Stamps can get troubles like mentioned in paragraph 3f above.
You mentioned needing "REVERSE and TURN" code. That is in the Toddler manual chapter 8. See the tables·named LBumper and RBumper.·I agree with Ken's comment that this table code can get difficult to follow but I have found the time spent·very worthwhile. Using tables like that is a very powerful technique.
For a discussion on DC power supplies, the Blue Bell website section called the tech center has some information you might find useful.
I realize I'm pretty late joining this thread so you may be finished your Toddler by now. But, is a Toddler, or any other robot, ever really finished? How did·yours turn out? What have you finally decided to implement?
Harry
Stamp Robotics to the next level
www.bluebelldesign.com