On May 29, 2006, at 11:43 AM, Hans-Christoph Steiner wrote:
I don't recall the exact specs for even a plain servo. It will
make your life much easier if you have a reference to what kind of
signal you are trying to send it. It should be quite easy to find,
just search the interweb using the manufacturer and part number, or
maybe even more generic info would work.
you are right! thing is that..as said, me (a plain user) will like to
be able to move the little motor either via [PWM] or just any of the
digital pins.. but unfortunately from my user level capacity this
doesnt seem to be easy, thought i keep the hope that its just my
blindness and lack of understanding of what the patch is doing...
reason why im so grateful to all you people out there openly
discussing about similar issues. :)
this are the specs taken from the interweb:
Abm.: (L x B x H) 23.7 x 12.8 x 22.5 mm Gewicht: 8 g Stell-Moment bei 4,8 V: 10 Ncm Stell-Zeit bei 4,8 V: 0.17 s Getriebe: Kunststoff Stell-Zeit bei 6 V: 0.15 s Typ: 8 Stell-Moment bei 6 V: 12 Ncm Steck-System: Futaba
a pdf here: http://www.produktinfo.conrad.com/datenblaetter/ 225000-249999/230501-da-01-en-TopLine_Mini-Servo_ES-05_FUT.pdf
an image here: http://www1.conrad.de/m/ 2000_2999/2300/2300/2305/230500_RB_00_FB.EPS.jpg
Tx for the help, again /a
hello,
servo's are _slightly_ different in that they dont take the classical pwm that you can regulate from 0..100%.
instead, a servo needs a repetetive pulse between 1 and 2 miliseconds. that pulse train can have a frequency from 30 to 400 hz, for example, but the pulse width stays in the same range. a pulse of 1.5 ms positions the servo into the center, 1 and 2 ms are for the full movement to the left or right respectively.
in the controller you need a loop (or, preferably, an interrupt) that just waits some 20 ms, then sets the pulse on, waits 1 to 2 ms, and turns off again, then repeat ....
greets,
chris
Am Montag, 29. Mai 2006 13:59 schrieb nomeparece:
On May 29, 2006, at 11:43 AM, Hans-Christoph Steiner wrote:
I don't recall the exact specs for even a plain servo. It will make your life much easier if you have a reference to what kind of signal you are trying to send it. It should be quite easy to find, just search the interweb using the manufacturer and part number, or maybe even more generic info would work.
you are right! thing is that..as said, me (a plain user) will like to be able to move the little motor either via [PWM] or just any of the digital pins.. but unfortunately from my user level capacity this doesnt seem to be easy, thought i keep the hope that its just my blindness and lack of understanding of what the patch is doing... reason why im so grateful to all you people out there openly discussing about similar issues. :)
this are the specs taken from the interweb:
Abm.: (L x B x H) 23.7 x 12.8 x 22.5 mm Gewicht: 8 g Stell-Moment bei 4,8 V: 10 Ncm Stell-Zeit bei 4,8 V: 0.17 s Getriebe: Kunststoff Stell-Zeit bei 6 V: 0.15 s Typ: 8 Stell-Moment bei 6 V: 12 Ncm Steck-System: Futaba
a pdf here: http://www.produktinfo.conrad.com/datenblaetter/ 225000-249999/230501-da-01-en-TopLine_Mini-Servo_ES-05_FUT.pdf
an image here: http://www1.conrad.de/m/ 2000_2999/2300/2300/2305/230500_RB_00_FB.EPS.jpg
Tx for the help, again /a
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Christian Klippel wrote:
hello,
servo's are _slightly_ different in that they dont take the classical pwm that you can regulate from 0..100%.
instead, a servo needs a repetetive pulse between 1 and 2 miliseconds. that pulse train can have a frequency from 30 to 400 hz, for example, but the pulse width stays in the same range. a pulse of 1.5 ms positions the servo into the center, 1 and 2 ms are for the full movement to the left or right respectively.
in the controller you need a loop (or, preferably, an interrupt) that just waits some 20 ms, then sets the pulse on, waits 1 to 2 ms, and turns off again, then repeat ....
...or a 50Hz pwm with a positive pulse width varying between 5 and 10 percent. Doing this from a soundcard output is bad because 50Hz is close to the low-frequency cutoff of the card, so the parts of the pulse that should be at either 0V or 5V will actually drift towards each other. You would need to add a comparator to get a digital level signal. The arduino digitalWrite command in conjunction with delayMicroseconds (for the positive pulse)and delay (for the negative pulse) should be OK for this. Martin
Martin Peach wrote:
Christian Klippel wrote:
hello,
servo's are _slightly_ different in that they dont take the classical pwm that you can regulate from 0..100%.
instead, a servo needs a repetetive pulse between 1 and 2 miliseconds. that pulse train can have a frequency from 30 to 400 hz, for example, but the pulse width stays in the same range. a pulse of 1.5 ms positions the servo into the center, 1 and 2 ms are for the full movement to the left or right respectively.
in the controller you need a loop (or, preferably, an interrupt) that just waits some 20 ms, then sets the pulse on, waits 1 to 2 ms, and turns off again, then repeat ....
...or a 50Hz pwm with a positive pulse width varying between 5 and 10 percent. Doing this from a soundcard output is bad because 50Hz is close to the low-frequency cutoff of the card, so the parts of the pulse that should be at either 0V or 5V will actually drift towards each other. You would need to add a comparator to get a digital level signal. The arduino digitalWrite command in conjunction with delayMicroseconds (for the positive pulse)and delay (for the negative pulse) should be OK for this.
Oh yes, and the arduino analogWrite (pwm) will not work because it splits the pwm signal into many small pulses so that it works better for audio.
Martin
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On May 29, 2006, at 5:35 PM, Martin Peach wrote:
Christian Klippel wrote:
hello, servo's are _slightly_ different in that they dont take the
classical pwm that you can regulate from 0..100%. instead, a servo needs a repetetive pulse between 1 and 2
miliseconds. that pulse train can have a frequency from 30 to 400 hz, for
example, but the pulse width stays in the same range. a pulse of
1.5 ms positions the servo into the center, 1 and 2 ms are for the
full movement to the left or right respectively. in the controller you need a loop (or, preferably, an interrupt)
that just waits some 20 ms, then sets the pulse on, waits 1 to 2
ms, and turns off again, then repeat .......or a 50Hz pwm with a positive pulse width varying between 5 and
10 percent. Doing this from a soundcard output is bad because 50Hz
is close to the low-frequency cutoff of the card, so the parts of
the pulse that should be at either 0V or 5V will actually drift
towards each other. You would need to add a comparator to get a
digital level signal. The arduino digitalWrite command in conjunction with
delayMicroseconds (for the positive pulse)and delay (for the
negative pulse) should be OK for this. Martin
So it should be possible to generate this signal in Pd and output it
via the serial port to control a digital output pin. The serial port
runs at 115,200 b/s, which is more than enough to control something
at 1-2ms. The question is whether you can get an steady stream. If
there is too much jitter, then it wouldn't work.
To make Pd do this is message space, you could change the block size
to a very small amount. I wonder if this would work...
.hc
"Computer science is no more related to the computer than astronomy
is related to the telescope."
-Edsger
Dykstra
Hans-Christoph Steiner wrote:
To make Pd do this is message space, you could change the block size to a very small amount. I wonder if this would work...
no, i am pretty sure it won't work. 1st because pd's synchronous scheduling is (at lesat: used to be when i last looked at it which is several versions ago) always at 64samples. if you have 32samples block~sizes, then you will just schedule 2 blocks each 64samples cycle. it is really the dacblocksize that defines the minimum reaction time. some months or years ago i posted a patch where you could set the dacblocksize at runtime. 2nd because the message system is basically asynchronous.
probably a good idea would be a [comport~] external.
mfg.adsr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
To make Pd do this is message space, you could change the block size to a very small amount. I wonder if this would work...
no, i am pretty sure it won't work. 1st because pd's synchronous scheduling is (at lesat: used to be when i last looked at it which is several versions ago) always at 64samples. if you have 32samples block~sizes, then you will just schedule 2 blocks each 64samples cycle. it is really the dacblocksize that defines the minimum reaction time. some months or years ago i posted a patch where you could set the dacblocksize at runtime. 2nd because the message system is basically asynchronous.
While changing the block size won't help with Pd's "64-sample limit" on the message transport, one could use clock-delayed messages to fire an event at an arbitrary time, even in the middle of a 64-samples block. Many builtin time-related objects (like del, metro, pipe, qlist etc, see "x_time.c") use clocks this way, but I guess (without looking), that somewhere in [comport] this information is discarded. Probably it shouldn't be discarded, if you want a timing resolution better than 64 samples.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
I guess (without looking), that somewhere in [comport] this information is discarded. Probably it shouldn't be discarded, if you want a timing resolution better than 64 samples.
I now had a quick look at comport.c and it already is using clocks for reading from the comport, but just writes to the port whenever messages come in, which is quantized to one block. So you'll get jitter. I think, introducing an unquantized timing similar to how vline~ in d_ctl.c handles it (by using "x->x_referencetime = clock_getlogicaltime();" and then working with "timenow = clock_gettimesince(x->x_referencetime);") could get rid of the jitter. It wouldn't be necessary to make a signal object [comport~].
At least that's what I believe: This clock stuff is quite confusing.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On May 30, 2006, at 9:02 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
To make Pd do this is message space, you could change the block
size to a very small amount. I wonder if this would work...no, i am pretty sure it won't work. 1st because pd's synchronous scheduling is (at lesat: used to be
when i last looked at it which is several versions ago) always at
64samples. if you have 32samples block~sizes, then you will just
schedule 2 blocks each 64samples cycle. it is really the
dacblocksize that defines the minimum reaction time. some months or
years ago i posted a patch where you could set the dacblocksize at
runtime. 2nd because the message system is basically asynchronous.probably a good idea would be a [comport~] external.
[comport~] sounds intriguing actually, I think it might be useful for
writing data at the full 115,200 bits/second (actually USB-serial
goes up to 1.5 Mbps). 115,200 sends 14,400 bytes every second, so
that means .07ms between bytes. This is roughly comparable to 11k,
8bit mono sound.
But there are other issues with serial communications. We (with Dan
Overholt, creator of the CUI http://www.create.ucsb.edu/~dano/CUI/)
did some informal measurement using the attached patch and an Arduino
set to echo any byte it receives. We measured a response time
between 0.5ms and 22ms, with an average around 12ms. So basically
there is a ton of jitter, a lot more than would seemingly be caused
by the Pd messaging rate.
I have a question about implementing [comport~]: audio data is
constantly running, yet generally, serial interfaces are used for
event-based messaging. Would it be possible to still send event
messages via a tilde object? Otherwise, you'd just have to use
[comport~] to transmit state constantly. But you would still need to
be able to interleave different data chunks, so that you can use one
[comport~] to control many outputs on an Arduino, for example.
Maybe we should also consider a [tcp~] and [udp~] for very low-
latency/low jitter messaging? Ethernet hardware has a latency of
0.3ms or perhaps less, so Pd's ~1.5ms between messages is a fair
amount higher than ethernet.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
Hans-Christoph Steiner wrote:
On May 29, 2006, at 5:35 PM, Martin Peach wrote:
Christian Klippel wrote:
hello, servo's are _slightly_ different in that they dont take the
classical pwm that you can regulate from 0..100%. instead, a servo needs a repetetive pulse between 1 and 2 miliseconds. that pulse train can have a frequency from 30 to 400 hz, for
example, but the pulse width stays in the same range. a pulse of 1.5 ms positions the servo into the center, 1 and 2 ms are for the full movement to the left or right respectively. in the controller you need a loop (or, preferably, an interrupt)
that just waits some 20 ms, then sets the pulse on, waits 1 to 2 ms, and turns off again, then repeat .......or a 50Hz pwm with a positive pulse width varying between 5 and 10 percent. Doing this from a soundcard output is bad because 50Hz is close to the low-frequency cutoff of the card, so the parts of the pulse that should be at either 0V or 5V will actually drift towards each other. You would need to add a comparator to get a digital level signal. The arduino digitalWrite command in conjunction with
delayMicroseconds (for the positive pulse)and delay (for the negative pulse) should be OK for this. MartinSo it should be possible to generate this signal in Pd and output it
via the serial port to control a digital output pin. The serial port
runs at 115,200 b/s, which is more than enough to control something at 1-2ms. The question is whether you can get an steady stream. If there is too much jitter, then it wouldn't work.
For controlling a servo the jitter between pulses isn't too important, it can be about 2ms. The pulse itself has to be more precise and between 1 and 2ms. If you do this with a serial byte, you only have about 5 different angles on the servo, since you can only send 0x00, 0x80, 0xC0, 0xE0, 0xF0 at some baud rate around 4000 to get pulses between 1 and 2 ms. (The pulse would be the start bit and up to 8 zero bits following it.) The other way is to toggle DTR. Not sure if comport lets you do this (I don't think ist does) but it would be useful just for controlling simple on/off things. To control a 90 degree servo to a precision of one degree you need pulse precision down to 1/90 ms or about 10 microseconds.
Also there is still the problem of voltage levels. The servo wants 0-5V, DTR could be 12V, and TXD is -12V - + 12V, so you need something before the servo, to reduce the voltage, could be just a couple of resistors.
The parallel port would be better for this (voltages are better and you have more pins to play with) but they seem to be on the road to extinction as well as harder to access than serial ports.
Something like this http://www.hvwtech.com/products_view.asp?CatID=113&SubCatID=146&SubS... is a better solution if you can't/don't want to build your own.
Martin
To make Pd do this is message space, you could change the block size to a very small amount. I wonder if this would work...
.hc
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
-
Christian Klippel -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
nomeparece