Will the servos Parallax sells work from a pulse directly from the Propeller?
CJ
Posts: 470
or will a buffer/shifter be necessary to get it to 5v?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Comments
just trembling at the robotics possibilities, servo controller object using global position variables!
position can be updated in mere microseconds after reading sensor data<--- this could be very interesting, maybe a biped that can catch itself if tipping/tripping
it is too much for my brain to take
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
it is, it can drive up to 32-servo's from the Propeller.
One, problem is that if you run ALL 32 servo's, you don't have any I/O's left for sending data back into the Propeller to update
servo positions unless you are running from a pre-defined algorithm internal to the Propeller. So an external multiplexing scheme
of some kind or limiting your total servo count to 31 could be used.
Servo_Demo - Propeller Spin code
CON _clkmode = xtal1 + pll16x _xinfreq = 4_000_000 'Note Clock Speed for your setup!! PanServo = 0 'Select DEMO servo to pan VAR OBJ SERVO : "Servo32" PUB Servo32_DEMO | temp repeat temp from 0 to 31 'Preset ALL servo's to center position SERVO.Set(temp,1500) 'Note: Servo pins that will be used must be preset before running "SERVO.Start". ' This is because the I/O direction is set here and is only executed ' at the beginning of "SERVO.Start". Servo pins that aren't used will remain ' in their original direction state. SERVO.Start 'Start Servo handler repeat 'Pan selected DEMO servo back-n-forth repeat temp from 1000 to 2000 waitcnt (cnt+125_000) SERVO.Set(PanServo,temp) repeat temp from 2000 to 1000 waitcnt (cnt+125_000) SERVO.Set(PanServo,temp)Servo32 - Propeller Assembly code
CON _1uS = 1_000_000 / 1 'Divisor for 1 uS ZonePeriod = 5_000 '5mS (1/4th of typical servo period of 20mS) NoGlitchWindow = 2_500 '2.5mS Glitch prevention window (set value larger than maximum servo width of 2mS) VAR long ZoneClocks long NoGlitch long ServoPinDirection long ServoData[noparse][[/noparse]31] '0-31 Servo Pulse Width information PUB Start ZoneClocks := (clkfreq / _1uS * ZonePeriod) 'calculate # of clocks per ZonePeriod NoGlitch := $FFFF_FFFF-(clkfreq / _1uS * NoGlitchWindow) 'calculate # of clocks for GlitchFree servos. Problem occurs when 'cnt' value rollover is less than the servo's pulse width. cognew(@ServoStart,@ZoneClocks) PUB Set(Pin, Width) 'Set Servo value Width := 1000 #> Width <# 2000 'limit Width value between 1000uS and 2000uS Pin := 0 #> Pin <# 31 'limit Pin value between 0 and 31 ServoData[noparse][[/noparse]Pin] := (clkfreq / _1uS * Width) #> 381 'calculate # of clocks for a specific Pulse Width dira[noparse][[/noparse]Pin] := 1 'set selected servo pin as an OUTPUT ServoPinDirection := dira 'Read I/O state of ALL pins DAT '********************* '* Assembly language * '********************* org '------------------------------------------------------------------------------------------------------------------------------------------------ ServoStart mov Index, par 'Set Index Pointer rdlong _ZoneClocks, Index 'Get ZoneClock value add Index, #4 'Increment Index to next Pointer rdlong _NoGlitch, Index 'Get NoGlitch value add Index, #4 'Increment Index to next Pointer rdlong _ServoPinDirection, Index 'Get I/O pin directions add Index, #32 'Increment Index to END of Zone1 Pointer mov Zone1Index, Index 'Set Index Pointer for Zone1 add Index, #32 'Increment Index to END of Zone2 Pointer mov Zone2Index, Index 'Set Index Pointer for Zone2 add Index, #32 'Increment Index to END of Zone3 Pointer mov Zone3Index, Index 'Set Index Pointer for Zone3 add Index, #32 'Increment Index to END of Zone4 Pointer mov Zone4Index, Index 'Set Index Pointer for Zone4 mov dira, _ServoPinDirection 'Set I/O directions '------------------------------------------------------------------------------------------------------------------------------------------------ Zone1 mov ZoneIndex, Zone1Index 'Set Index Pointer for Zone1 mov ZoneShift, #0 call #ZoneCore Zone2 mov ZoneIndex, Zone2Index 'Set Index Pointer for Zone2 mov ZoneShift, #8 call #ZoneCore Zone3 mov ZoneIndex, Zone3Index 'Set Index Pointer for Zone3 mov ZoneShift, #16 call #ZoneCore Zone4 mov ZoneIndex, Zone4Index 'Set Index Pointer for Zone4 mov ZoneShift, #24 call #ZoneCore jmp #Zone1 '------------------------------------------------------------------------------------------------------------------------------------------------ ZoneCore mov SyncPoint, cnt 'Create a Sync Point with the system counter mov temp, _NoGlitch 'Test to make sure 'cnt' value won't rollover within Servo's pulse width sub temp, cnt wc 'Subtract NoGlitch from cnt ; write result in C flag if_C jmp #ZoneCore 'If C flag is set get a new Sync Point, otherwise we are ok. ZoneLoop mov ServoByte, #0 'Clear ServoByte mov LoopCounter, #8 'Set LoopCounter mov Index, ZoneIndex 'Set Index Pointer for proper Zone ServoLoop rdlong ServoWidth, Index 'Get Servo Data add ServoWidth, SyncPoint 'Determine system counter location where pulse should end sub ServoWidth, cnt wc 'subtract system counter from ServoWidth ; write result in C flag rcl ServoByte, #1 'Rotate "C Flag" right into ServoByte sub Index, #4 'Decrement Index pointer to next address djnz LoopCounter, #ServoLoop 'Decrement LoopCounter; Jump to ServoLoop if not "0" xor ServoByte, #$FF 'Invert ServoByte variable shl ServoByte, ZoneShift 'Shift data to proper port or Zone location. mov outa, ServoByte 'Send ServoByte to Zone Port mov temp, _ZoneClocks 'Move _ZoneClocks into temp add temp, SyncPoint 'Add SyncPoint to _ZoneClocks sub temp, cnt wc 'Determine if cnt has exceeded width of _ZoneClocks ; write result in C flag if_NC jmp #ZoneLoop 'if the "C Flag" is not set stay in the current Zone ZoneCore_RET ret '------------------------------------------------------------------------------------------------------------------------------------------------ temp res 1 Index res 1 ZoneShift res 1 ZoneIndex res 1 Zone1Index res 1 Zone2Index res 1 Zone3Index res 1 Zone4Index res 1 SyncPoint res 1 ServoWidth res 1 ServoByte res 1 LoopCounter res 1 '------------------------------------------------------------------------------------------------------------------------------------------------ _ZoneClocks res 1 _NoGlitch res 1 _ServoPinDirection res 1▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 3/16/2006 6:37:21 PM GMT
I can see an object of type Servo... [noparse]:)[/noparse]
Question, how could you multiplex the servo inputs (propeller outputs) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
.spin object that that drives up to 14 servos.· While it's not the optimal assembly language
object from Beau (above), it will fit nicely into classes where assembly language is neither a
prerequisite, nor a course goal.·
Fully commented code is attached and condensed code screen captures are below.· Please
keep in mind that this is a work in progress.· The final version you see in a text will likely
have more flexibility and features.·
As Jon mentioned, the object gets servo pulse durations from the·program that declared it.
Here is an example of a top level object that sends 2.5 ms pulses to 14 servos.· All this
program does is store 1000 in each of the 14 servo array elements.· As soon as the Servos
object's .start method is called, the Servos object starts looking at the contents of each
of the array elements in this top file every 20 ms.
If a servo array element contains a 0, the Servos object delivers 1.5 ms pulses.· You can
add or subtract from the variable to increase or decrease the pulse by a certain number of
microseconds.· In this program, all the servo[noparse][[/noparse]i] elements store 1000, so all fourteen servos
are getting 2.5 ms pulses every 20 ms.
Here is another example of a program that sweeps the pulse durations of two servos back
and forth between 0.5 ms to 2.5 ms while holding a third at center.
Again, keep in mind, as soon as the value of an element in the servo array is updated, the
pulse the Servos object delivers will be updated during the next pulse.
Here is the Servos object that the previous two programs use.··It's running in its own cog, and this is
the magic command that looks into its parent object's array variables.
· long[noparse][[/noparse]address][noparse][[/noparse]pin + 1 - sPin]
If you look back at the previous two example programs, you will see that they pass the address of their
servo arrays with a command like this:
s.start(start pin, end pin, @array address)
Post Edited (Andy Lindsay (Parallax)) : 3/16/2006 7:51:20 PM GMT
As Andy mentions, "this is a work in progress". There will most likely be a Servo object.
Now I can't give away all my secrets....
something that uses a couple of transistors to form a latched output, while "toying" with
the threshold differences between the Propeller (1.65V) and the P-N junction threshold
of a transistor (.6V to .7V).... <--"idea in progress"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
vsc.setpos(0, 1500)
where vsc is the declared object, and setpos is a method that takes a channel and position value in microseconds. In my version you don't have to delcare local variables for the servos, though you do pass an array (stored in a DAT table) of default positions for the start and reset methods. I'm also working on a method that enable you to control the servo speed from one position to the next -- like the "ramp" feature in the PSC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Readable and understandable... Aside from syntax, I understood what you were doing through. I even picked out that the routine is clock speed indipendent (sp), I think.
Beau, when you get the "Servo Multiplexer" to work, it's gonna be a big time helper to many...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
>Question, how could you multiplex the servo inputs (propeller outputs) ?
A shift register tranferring a single high bit from servo to servo at the appropriate time is pretty
simple and cheap. In terms of i/o it costs one pin to feed the data to n shift registers and one clock
pin per shift register, so 32 servos would need five i/o if the registers are 8 bits long like conventional
R/C decoders, but they could be longer without decreasing the refresh rate since no sync time is required.
I actually understood what you were saying, as I'm getting a good 'crash' course in electronics from a lot of people here. This is a good thing.
I know it's old hat for most of you, but I just relized that a spin or asm routine in a cog could output a very accurate clock pulse on a pin, very easily. A 'Clock Output' type object.
While lots of folks, like Tracy Allen and the likes are light years infront of me, I'm sure with some logic one could build a rather robust Clock object.
Heck, if it's done right, it could be as accurate and good as a RTC chip... I think....
Is anyone working on a object like this?
I just relized another thing: I post a heck of a lot of 'I Thinks' and not a lot of 'I Knows'....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Lets say for example I need 28 servos, can I delcare Jon's object (that maxes out at 14 servos) twice?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Now how much current does each servo draw when being pulsed. We have been told 50 ma max per pin, but no total (as with the BS2 which is 20 per pin, 40 ma total per 8 pins, etc) has been given. Can we infer anything from 8x50 here? or is it just a convenient grouping not directly related.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
The reference is to the current draw on the total system, not on the individual I/O's.
Through a 4.7K resistor the maximum I/O current required for 32 servos is only 22mA.
Suppose each servo required 200mA under a load ... 200mA x 32 = 6.4 Amps
A 6.4 Amp surge can easily cause enough of a·spike on the entire system to cause problems.
Reducing the possibility to 8 servo's limits the amount of surge current to 1.6 Amps.·
Still a fair amount of current, but·somewhat easier to deal with than 6.4 Amps.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 4/5/2006 10:36:53 PM GMT
power from the red (Futaba) wire in the connector rather than the signal pin so it doesn't affect the microcontroller directly. However, a
standard servo can draw about 1 amp peak when it has a lage error signal (difference between commanded and actual position) which
can cause the the supply voltage to droop. Pulsing the servos sequentially minimizes the peak current and reduces the chances of
causing the microcontroller to reset.
Russ
Understood. The rule thumb has always been to have the servo's driven from a separate power supply than the processor, but even then being able to space the peaks out to 1.6 amps per period rather the cyclical spikes of 6.4 amps will make for a much happier power supply.
I guess that brings me back to my orginal curiosity. We have yet to get a figure beyond 50 ma per pin, is there a overal chip or per 8 pin groupp limit a well or is just 8x50ma ... I guess i just don't have a real feel for the drains of the more common loads. With a BS2 we are usually looking at series protective resistors of 220 or 330 ohms, seires current limiting resistors for LEDs of 220 p to 1K, and 1K or 2K with 2N2222 or 2N3904 keying/switching transistors. they all draw very little, I would imagine few people ever actually seriously push the limit, except accidently. So when I saw the propeller with 50 ma per pin I was surprised and it makes me wonder what the limit on the chip or pin group is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
But it all makes sense, and there will only be 1 copy of the code operating at a time, right?
I still need to find a "good" way to multiplex the servos... I might end up getting the servo controller for this project...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
The circuit below doesn't "multiplex the servos" but it does take advantage of the voltage threshold differences between
the Propeller (1.65V) and a standard transistor (approx .6V). With a little bit of hand-shaking from the device trying to
pass data into the Propeller this method does work.
Note: A complementary transistor version of this circuit might be better suited for data transfer with servo's, since the
majority of the signal time is spent in the logic LOW position. (This is still under test)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Since you're going to use parts, how about this (which I did not design) with something clamp CLK to 3.3V, and maybe a different C1 -
I think this has the same function as the old NE5045 r/c decoder chip. 8-10 servos on one pin. 300 servo controller anyone?
more info homepages.tesco.net/ada.tippett/Radio6.htm
edit: On second thought, 300 might be tough since you would have to service a minimum of 4 4017 counters/cog and the pulse end times on diferent counters could overlap.
Post Edited (Russ Miller) : 4/6/2006 5:47:41 AM GMT
The 4017 is simply a decade counter/divider, and would work, but I wanted to keep the component count down to a minimum. Something that needs to be considered with
the above option is that the Clock pulse will vary it's period from 1mS to 2mS corresponding to the servos value. As a result you will need to subtract 20mS from the sum
of all 8 servo values and apply the result as a final delay to maintain the 20mS servo "OFF-time" that the servos require before you start the sequence all over again.
10 servos per 4017 would be the absolute maximum limit, but you also need to figure in the processor overhead required to retrieve the servo value and clock the pin correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
Post Edited (Kaos Kidd) : 4/6/2006 6:19:03 PM GMT
With ANY type of polling scheme where you do one servo, then the next, the next, and so on. You are going to be limited to a MAXIMUM of 10 servos.
The reason is because each servo expects an update pulse every 15 to 25 mS (20mS is the standard). Since each servo has a maximum position pulse
of 2mS, then 10 servos x 2mS per servo equals 20mS. This assumes you can fit any signal processing overhead within the pulses.
Even though the 4067B can multiplex 16 individual channels, the time frame required at each channel will not agree with what the servo wants.
The way that my example program does it for 8 servos within a 5mS window is by setting ALL 8 servo pins high, and then individually dropping them low
after the specified amount of time (1-2mS) has elapsed for each channel. Doing this, all of the servos complete their pulse within 2mS, and there is 3mS
to spare for signal processing before the next group of 8 servos are activated. Do this 4 times at 5mS a piece, and the servos get their 20mS requirement.
Now, saying that... what you could do is use 4·octal buffer·IC's to direct 8 of the servo I/O pins to the 32 servo's.· In addition you would need 2 I/O lines
to select which octal buffer of the 4 is selected at a time.· So a total of 10 I/O's for 32 servo's.· With this, the current program would even get smaller
because you would not need to deal with Zones other than setting 2 I/O's to correspond to the correct external octal buffer (Zone)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 4/6/2006 6:59:07 PM GMT
I understand how your example program works now, much better, the math was simply running away from me.
Ok, I like your example better, now that I actually understand (no fault of anyones but myself) how and why it works.
I'm going to see what else I can find on this...
Thanks again Beau.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Add a few decupling caps, and it should be good to go.
Thanks again!
Fred
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
Yeah, that is something like what I was describing, but you might need to put a pull down resistor on each output to the servo.
I was trying to look for a latched output version to eliminate the pull-down resistors, and a 74xx573 or 74xx373 would work,
but I couldn't find a 2-4 decoder that was active HIGH.
Sacrifice 2 more pins and you wouldn't need the decoder, just use 4 octal buffers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
It would keep the part count down, and this is something I should be able to make without worrying too much about the lack of expierence in pcb creation. I'll add to the schmatic above for the finalized version of the board, and go from there.
And Beau, again, I can't express my thanks. I will make this work... One way or another!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
I'm not sure as to why the difference between the '573 and the 541 makes it so I don't need the pull-down. (could you explain this ?)
Also, I assume we need to hook the latch in to the circuit as well, there for needing 1 additional pin. (Unless you have a better idea...)
Total pin count: 13 ( 8 for servos, 4 for zone select, 1 for latch)
Max servos: 32
Total device count: 4 * 74XXX573
.....
Make the object so the lines can be passed in chuncks (ie servo lines, crlt, select lines) then
Then you could make two instances of the servo object, sharing the ctrl + select lines, adding 8 more lines (for the second servo set), sync the select lines,
and you get 64 servos for the total cost of 21 lines... Not bad... Not bad at all.
.....
Did I finally get it?
...EDITED.... I forgot to attach the image!!! ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
Post Edited (Kaos Kidd) : 4/7/2006 6:08:22 PM GMT
The 541 is just a gated octal buffer, when it is not selected the outputs float...· servo's would not like this feature.
The 573 is a·latched octal buffer.
What you should do is enable (OE) the outputs to all four buffers by tying them to ground, and use the Latch enable (LE)
for your control signal to each buffer.· Your schematic looks like it is using the output enable to control the buffer, you only
need to control the·latch enable.
From the PDF:
These 8 bit D-Type latches are controlled by a latch ·enable input (LE) and a output enable input (OE).
While the LE input is held at a high level, the Q·outputs will follow the data input precisely(573) or ·inversely(563).
When the LE is taken low, the Q outputs·will be latched precisely(573) or inversely(563) at the logic level of D input data.
While the OE input is at low level, the eight outputs will be in a normal logic state (high or low logic level) and while high level
the outpts will be in a high impedance state.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Got ya. I'll fix that on the drawing and I'll be good to go...
Next time I'll read ALL the pdf, not just the parts I like... [noparse]:)[/noparse]
And thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·