SX Servo/LED/PWM Controller -- Real-time Ramping, Group Moves, Multiplexing, Et
Video of controller being used by Stamp 'bot to run servos:
The video shows one of my bigger 'bots using the SX Q-controller for servo control. One note about the video: the 'bot is wayyyy over responsive to obstacles -- this is because I have not yet re-tuned my PID routines -- the new servo controller has cut a *lot* of time out of my main loop (used to be I was getting 5-8 loops through the main program per second; now it's much closer to 20) -- www.youtube.com/watch?v=9PGgkRUSlDY
New Code Posted 25 jan 2008 -- fixes significant bug that caused 16bit overflow when scaling brad positions (depending on scale word value). Added new "center all" command, freed up a lot of code space, updated comments.
On Saturday I put together the protoboard version of an SX-based servo-controller and LED multiplexer (or PWM outs). Serious kudos to Jon Williams SX servo/animatronic controller in N/V which contained the seeds of the code and the motivation for doing this.
I have a PSC in my largest 'bot, but I wanted to replace with it something more customized to my needs. I love the PSC, but it has a few drawbacks for my purposes -- primarily the lack of real-time ramping and group moves, and more importantly, the huge overhead in the number of bytes that need to be transmitted. My particular 'bot requires that 5 servos are updated with new positions AND the current positions read back to the host on every pass through the main loop -- on the PSC this means a *whopping* 80 bytes need to go back and forth on every cycle. Even at 38K4 the time was pretty substantial.
My controller allows for updating 8 servos with a MAXIMUM of 20 bytes, reading positions takes a max of 10.
Additionally, I set up a few other conveniences to offload a lot of work from the host:
- real-time ramping -- moves servo(s) to new position in a set amount of TIME, regardless of starting position or destination position.
- group moves -- move any and all servos to new positions in the same amount of time, regardless of distance each servo has to travel
- servos may be calibrated to BRADS, so that 0-64-128 brads delivers 0.5-1.0-2.5 ms pulses (final actual pulsewidths can be individually calibrated to each servo). The host can switch the controller between brad-calibrated positions (0-64-128) and "byte" positions (0-128-255) at any time via serial command.
- one byte of servo "flags" may be requested -- a servo's bit flag is set if the servo has *actually* been sent the final target position. This is useful during group moves or slow ramps and you want an answer to the question "has the servo(s) reached the position I told it to go to"
- "mirror" servo -- servo may be set to mirror the target position (useful when using matching but mirrored pan/tilt assemblies and the like)
- calibrated offsets -- if a 1.5ms pulse is not the "physical" center that is desired for a given servo, the servo can be calibrated to have a different center offset.
- two banks (digits) of 8 segments (leds) for a total of 16 leds may be multiplexed from 10 pins. There is also individual PWM dimming control of each bank (digit). Additionally, the host can switch the controller into PWM/discrete mode at any time -- this allows the user to use the LED pins as two individual 8-bit PWM outs and use the LED anode port as 8 discrete digital outputs.
- status/power LED is wired to a pin on RA -- I currently have it set for 50% brightness during normal program time, and it blinks bright when there is serial activity. This LED could be programmed for any "status" purpose, natch.
- serial baud rate from 2400-38K4. Baud rate may be changed at any time by the host via serial command
- reset pin has been brought out to the serial/host header -- this allows the host to perform a hard reset on the controller if necessary
- I couldn't fit 8 servo headers on the protoboard; since I only need 5 for my current project, I just built 7 headers. But the 8th could probably be fit in if you're cleverer than I.
- instead of regular DIP socket, I used two rows of SIP machine sockets -- this let me squeeze a bit of wiring underneath the SX.
- I did not put a large cap on the V+/V- servo power because my current projects have 6v power supplies with large caps already, but if you build this standalone you might want to squeeze in a 330-470uf bypass cap after the servo power terminal block
Downsides? Due to ISR contraints, the resolution of the servo pulsewidths is somewhat coarse 6.51us per unit (vs. 2us for the PSC). Since I usually work in brads anyway (which are even coarser) I decided to live with it. Second, the *actual* pulsewidth range available is .67us - 2.33 us (or 11-117 brads). I am going to rework code sometime over next few weeks to extend the range, but that entails setting up Word values for the pulsewidth management, and I just didn't have it in me this week to do the assembly work
. For now, values outside that range (if in brads) are limited by the application.
I have a video of a BS2 using the breadboard version of the controller to run 16 leds and 3 servos, but haven't had a chance to convert it. But if you've seen 16 leds and 3 servos, you've seen 'em all
Photos, schematic, code attached. The BS2 code is just quick'n'dirty code to test out the controller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 2/11/2008 5:24:15 PM GMT
The video shows one of my bigger 'bots using the SX Q-controller for servo control. One note about the video: the 'bot is wayyyy over responsive to obstacles -- this is because I have not yet re-tuned my PID routines -- the new servo controller has cut a *lot* of time out of my main loop (used to be I was getting 5-8 loops through the main program per second; now it's much closer to 20) -- www.youtube.com/watch?v=9PGgkRUSlDY
New Code Posted 25 jan 2008 -- fixes significant bug that caused 16bit overflow when scaling brad positions (depending on scale word value). Added new "center all" command, freed up a lot of code space, updated comments.
On Saturday I put together the protoboard version of an SX-based servo-controller and LED multiplexer (or PWM outs). Serious kudos to Jon Williams SX servo/animatronic controller in N/V which contained the seeds of the code and the motivation for doing this.
I have a PSC in my largest 'bot, but I wanted to replace with it something more customized to my needs. I love the PSC, but it has a few drawbacks for my purposes -- primarily the lack of real-time ramping and group moves, and more importantly, the huge overhead in the number of bytes that need to be transmitted. My particular 'bot requires that 5 servos are updated with new positions AND the current positions read back to the host on every pass through the main loop -- on the PSC this means a *whopping* 80 bytes need to go back and forth on every cycle. Even at 38K4 the time was pretty substantial.
My controller allows for updating 8 servos with a MAXIMUM of 20 bytes, reading positions takes a max of 10.
Additionally, I set up a few other conveniences to offload a lot of work from the host:
- real-time ramping -- moves servo(s) to new position in a set amount of TIME, regardless of starting position or destination position.
- group moves -- move any and all servos to new positions in the same amount of time, regardless of distance each servo has to travel
- servos may be calibrated to BRADS, so that 0-64-128 brads delivers 0.5-1.0-2.5 ms pulses (final actual pulsewidths can be individually calibrated to each servo). The host can switch the controller between brad-calibrated positions (0-64-128) and "byte" positions (0-128-255) at any time via serial command.
- one byte of servo "flags" may be requested -- a servo's bit flag is set if the servo has *actually* been sent the final target position. This is useful during group moves or slow ramps and you want an answer to the question "has the servo(s) reached the position I told it to go to"
- "mirror" servo -- servo may be set to mirror the target position (useful when using matching but mirrored pan/tilt assemblies and the like)
- calibrated offsets -- if a 1.5ms pulse is not the "physical" center that is desired for a given servo, the servo can be calibrated to have a different center offset.
- two banks (digits) of 8 segments (leds) for a total of 16 leds may be multiplexed from 10 pins. There is also individual PWM dimming control of each bank (digit). Additionally, the host can switch the controller into PWM/discrete mode at any time -- this allows the user to use the LED pins as two individual 8-bit PWM outs and use the LED anode port as 8 discrete digital outputs.
- status/power LED is wired to a pin on RA -- I currently have it set for 50% brightness during normal program time, and it blinks bright when there is serial activity. This LED could be programmed for any "status" purpose, natch.
- serial baud rate from 2400-38K4. Baud rate may be changed at any time by the host via serial command
- reset pin has been brought out to the serial/host header -- this allows the host to perform a hard reset on the controller if necessary
- I couldn't fit 8 servo headers on the protoboard; since I only need 5 for my current project, I just built 7 headers. But the 8th could probably be fit in if you're cleverer than I.
- instead of regular DIP socket, I used two rows of SIP machine sockets -- this let me squeeze a bit of wiring underneath the SX.
- I did not put a large cap on the V+/V- servo power because my current projects have 6v power supplies with large caps already, but if you build this standalone you might want to squeeze in a 330-470uf bypass cap after the servo power terminal block
Downsides? Due to ISR contraints, the resolution of the servo pulsewidths is somewhat coarse 6.51us per unit (vs. 2us for the PSC). Since I usually work in brads anyway (which are even coarser) I decided to live with it. Second, the *actual* pulsewidth range available is .67us - 2.33 us (or 11-117 brads). I am going to rework code sometime over next few weeks to extend the range, but that entails setting up Word values for the pulsewidth management, and I just didn't have it in me this week to do the assembly work
. For now, values outside that range (if in brads) are limited by the application.I have a video of a BS2 using the breadboard version of the controller to run 16 leds and 3 servos, but haven't had a chance to convert it. But if you've seen 16 leds and 3 servos, you've seen 'em all
Photos, schematic, code attached. The BS2 code is just quick'n'dirty code to test out the controller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 2/11/2008 5:24:15 PM GMT
1600 x 1200 - 835K
1600 x 1200 - 699K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Looks really tight. Nice!
Over in the SX forums we had a small debate about real cost of projects like this -- the SX-Key or SX-Blitz aside, the total cost on this was about $7. I buy headers, resistors, etc. in bulk a few hundred at a time, so parts like that are pennies. The biggest cost is the chip, resonator and the poorly made (but highly convenient and cheap) Radio Shack protoboards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
On one bot, I use the 10 of the 16 available LEDs as running lights and for patterns on the side of the 'bot; on another I use 6 of them as status indicators. I was mostly interested in servo control, and having an output port expander is always nice -- I figured I'd lay in the multiplex and PWM outs for flexibility.
At some point I might revisit the code and allow for using port RC as mutliplexed LEDs, or as digital outputs AND inputs -- then you'd have a tidy little 8-pin I/O expander combined with 8 servo ports.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Excellent job on the robot! Looks very cool. I like the way you've got the eye's looking around to see where he's going. What are you using for the speech?
It looks like you've built it all on the same chassis as the one in Tod Loofbourrow's book "How to build a computer-controlled robot" but you upgraded all the electronics and have the two drive wheels forward instead. I think it makes more sense just using a castor in the back instead of another motor as the book had suggested.
Quite an update from using a KIM-1 as the brain.
Robert
Speech is the *male* Emic TTS.
When the 'bot is done I'll be posting a full workup.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Carl
BTW, still have the book and was wondering whatever happened to Todd?
Founder/CEO, gotta be him: www.authoria.com/about/our-team.
The book: www.amazon.com/How-build-computer-controlled-robot-Loofbourrow/dp/0810456818/
Gotta say, though, in general, I like things wayyyyyyy better now. Servos instead of steppers (for hobby robotics, anyway); non-volatile program space; cheap, rugged chips with low part counts; everything smaller and less energy hungry; jack the processor(s) into your laptop and you're in business.
Also, what was it back then with platforms always being "steered" like tricycles? Because nobody had thought up an H-bridge so that differential steering is a lot easier on the circuit end? The geometry for true steering, vs. differential steering, is so much more complex. And, in the case of the orig. 3-wheel drive design of Tod's chassis, w/o differential drive on the rear wheels, turns were kind of insane.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 2/1/2008 8:51:17 PM GMT