RCservo functions

Based on DMP's Vortex processor / SoC this board is a full computer capable of running a standard Windows and Linux installation on the backpack of your robot.
5 postsPage 1 of 1
5 postsPage 1 of 1

RCservo functions

Post by Xinux » Sun Sep 19, 2010 5:46 am

Post by Xinux
Sun Sep 19, 2010 5:46 am

rcservo_SendPWMPulses(int channel, unsigned long period, unsigned long duty, unsigned long count)

How is this used to control a servo motor? What do period duty and count control? How would I go about figuring out how to move the motor a half a degree for instance?
rcservo_SendPWMPulses(int channel, unsigned long period, unsigned long duty, unsigned long count)

How is this used to control a servo motor? What do period duty and count control? How would I go about figuring out how to move the motor a half a degree for instance?
Xinux offline
Newbie
Newbie
Posts: 2
Joined: Sun Sep 19, 2010 5:43 am

Post by PaulL » Sun Sep 19, 2010 1:49 pm

Post by PaulL
Sun Sep 19, 2010 1:49 pm

Channel defines which PWM output to use.
Period defines the frequency of the PWM pulse.
Duty is the "high" duration of the PWM signal.
Count is the number of PWM pulses to send.

PWM for servos isn't absolute, different servos move different amounts depending on the duty. How much movement you get for a specified duty depends on the servo.

SendPWMPulses isn't constant, it only sends a pulse train of a specified number of pulses.

For values when calling this function, have a look at rcservo_SetServo to see what different values are for some of the predefined servos.

In building my own driver, I use the "continuous" mode of the PWM generator on Roboard, and I do not intend to read back servo positions at present. To do the same in RoboIO, you might try using the PWM lib directly.

Otherwise, there are other methods for using RoboIO to control servos, I think a few of those have been posted, maybe one of the guys using the RC Servo code will chime in if you want to do that instead of trying to use this function. :)
Channel defines which PWM output to use.
Period defines the frequency of the PWM pulse.
Duty is the "high" duration of the PWM signal.
Count is the number of PWM pulses to send.

PWM for servos isn't absolute, different servos move different amounts depending on the duty. How much movement you get for a specified duty depends on the servo.

SendPWMPulses isn't constant, it only sends a pulse train of a specified number of pulses.

For values when calling this function, have a look at rcservo_SetServo to see what different values are for some of the predefined servos.

In building my own driver, I use the "continuous" mode of the PWM generator on Roboard, and I do not intend to read back servo positions at present. To do the same in RoboIO, you might try using the PWM lib directly.

Otherwise, there are other methods for using RoboIO to control servos, I think a few of those have been posted, maybe one of the guys using the RC Servo code will chime in if you want to do that instead of trying to use this function. :)
PaulL offline
Savvy Roboteer
Savvy Roboteer
Posts: 423
Joined: Sat Sep 15, 2007 12:52 am

Post by Xinux » Sun Sep 19, 2010 8:29 pm

Post by Xinux
Sun Sep 19, 2010 8:29 pm

Ahh I see, I got the servo to move and I always set the frequency at 20000.
I was testing a continuous rotation servo, the dead zone (stop value) seems to be in the range of 1529 and 1555. I want to use this servo to move a sonic sensor left or right so that it scans for objects. So I made a function to turn the servo motor left and then to turn it back right again back to straightforward position. But this is inaccurate, it moves left so much, and then right too much, it never makes it back to a straightforward position. Is there anyway to do this?
Ahh I see, I got the servo to move and I always set the frequency at 20000.
I was testing a continuous rotation servo, the dead zone (stop value) seems to be in the range of 1529 and 1555. I want to use this servo to move a sonic sensor left or right so that it scans for objects. So I made a function to turn the servo motor left and then to turn it back right again back to straightforward position. But this is inaccurate, it moves left so much, and then right too much, it never makes it back to a straightforward position. Is there anyway to do this?
Xinux offline
Newbie
Newbie
Posts: 2
Joined: Sun Sep 19, 2010 5:43 am

Post by PaulL » Sun Sep 19, 2010 8:49 pm

Post by PaulL
Sun Sep 19, 2010 8:49 pm

Continuous rotation servos will do that. :) For a continous rotation servo, the mid-position (feedback for rotational position) is fixed to give you rotation in either direction proportionally as your signal deviates away from center. The speed difference you see is likely due to the motor itself. Motors always work better in one direction than the other, typically at the motor shaft itself, counter-clockwise will be faster. It has to do with the timing of the motor. You will never have perfect control of the revolutions without an additional sensor, continous servos don't have feedback, so you can't be sure of position.

You have a few options:

* Set up limit switches to actuate at extents of travel, and have Roboard stop sending pulses when limit switches attached to GPIO are triggered.
* Set up an optical encoder (a few ways to do this, from an LED / phototransistor pair to a "real" optical encoder depending on the resolution you need) for measuring turns and feed these back into GPIO. You could even use a tiny magnet on one side of your shaft and a reed switch.
* Rework to include a "regular" (non-continuous rotation) servo, and your position will be whatever it is set to from Roboard. Sweep the position to move your sensor.

You could also build a circuit to inhibit the signal to the servo when the limit switches are reached instead of using GPIO pins, that should work as well.

Personally, I'd use a standard servo, it's the easiest method. :)

Another quick note, if you go with a standard servo, it will be even easier to do "tracking", such that if a near object moves, you move left just a bit, sample, sample, sample, move right just a bit, sample, sample, sample, then move to the point of signal indicating closest object. Have a set-point for distance change, then repeat "peaking" to find closest point when current distance +/- set point is not equal to value when object found.
Continuous rotation servos will do that. :) For a continous rotation servo, the mid-position (feedback for rotational position) is fixed to give you rotation in either direction proportionally as your signal deviates away from center. The speed difference you see is likely due to the motor itself. Motors always work better in one direction than the other, typically at the motor shaft itself, counter-clockwise will be faster. It has to do with the timing of the motor. You will never have perfect control of the revolutions without an additional sensor, continous servos don't have feedback, so you can't be sure of position.

You have a few options:

* Set up limit switches to actuate at extents of travel, and have Roboard stop sending pulses when limit switches attached to GPIO are triggered.
* Set up an optical encoder (a few ways to do this, from an LED / phototransistor pair to a "real" optical encoder depending on the resolution you need) for measuring turns and feed these back into GPIO. You could even use a tiny magnet on one side of your shaft and a reed switch.
* Rework to include a "regular" (non-continuous rotation) servo, and your position will be whatever it is set to from Roboard. Sweep the position to move your sensor.

You could also build a circuit to inhibit the signal to the servo when the limit switches are reached instead of using GPIO pins, that should work as well.

Personally, I'd use a standard servo, it's the easiest method. :)

Another quick note, if you go with a standard servo, it will be even easier to do "tracking", such that if a near object moves, you move left just a bit, sample, sample, sample, move right just a bit, sample, sample, sample, then move to the point of signal indicating closest object. Have a set-point for distance change, then repeat "peaking" to find closest point when current distance +/- set point is not equal to value when object found.
PaulL offline
Savvy Roboteer
Savvy Roboteer
Posts: 423
Joined: Sat Sep 15, 2007 12:52 am

Post by clarkden » Tue Sep 28, 2010 1:47 am

Post by clarkden
Tue Sep 28, 2010 1:47 am

RN1AsOf091407 wrote:Continuous rotation servos will do that. :) For a continous rotation servo, the mid-position (feedback for rotational position) is fixed to give you rotation in either direction proportionally as your signal deviates away from center. The speed difference you see is likely due to the motor itself. Motors always work better in one direction than the other, typically at the motor shaft itself, counter-clockwise will be faster. It has to do with the timing of the motor. You will never have perfect control of the revolutions without an additional sensor, continous servos don't have feedback, so you can't be sure of position.

You have a few options:

* Set up limit switches to actuate at extents of travel, and have Roboard stop sending pulses when limit switches attached to GPIO are triggered.
* Set up an optical encoder (a few ways to do this, from an LED / phototransistor pair to a "real" optical encoder depending on the resolution you need) for measuring turns and feed these back into GPIO. You could even use a tiny magnet on one side of your shaft and a reed switch.
* Rework to include a "regular" (non-continuous rotation) servo, and your position will be whatever it is set to from Roboard. Sweep the position to move your sensor.

You could also build a circuit to inhibit the signal to the servo when the limit switches are reached instead of using GPIO pins, that should work as well.

Personally, I'd use a standard servo, it's the easiest method. :)

Another quick note, if you go with a standard servo, it will be even easier to do "tracking", such that if a near object moves, you move left just a bit, sample, sample, sample, move right just a bit, sample, sample, sample, then move to the point of signal indicating closest object. Have a set-point for distance change, then repeat "peaking" to find closest point when current distance +/- set point is not equal to value when object found.


thanks for the information

Clarkden
RC Hobby Shop
RN1AsOf091407 wrote:Continuous rotation servos will do that. :) For a continous rotation servo, the mid-position (feedback for rotational position) is fixed to give you rotation in either direction proportionally as your signal deviates away from center. The speed difference you see is likely due to the motor itself. Motors always work better in one direction than the other, typically at the motor shaft itself, counter-clockwise will be faster. It has to do with the timing of the motor. You will never have perfect control of the revolutions without an additional sensor, continous servos don't have feedback, so you can't be sure of position.

You have a few options:

* Set up limit switches to actuate at extents of travel, and have Roboard stop sending pulses when limit switches attached to GPIO are triggered.
* Set up an optical encoder (a few ways to do this, from an LED / phototransistor pair to a "real" optical encoder depending on the resolution you need) for measuring turns and feed these back into GPIO. You could even use a tiny magnet on one side of your shaft and a reed switch.
* Rework to include a "regular" (non-continuous rotation) servo, and your position will be whatever it is set to from Roboard. Sweep the position to move your sensor.

You could also build a circuit to inhibit the signal to the servo when the limit switches are reached instead of using GPIO pins, that should work as well.

Personally, I'd use a standard servo, it's the easiest method. :)

Another quick note, if you go with a standard servo, it will be even easier to do "tracking", such that if a near object moves, you move left just a bit, sample, sample, sample, move right just a bit, sample, sample, sample, then move to the point of signal indicating closest object. Have a set-point for distance change, then repeat "peaking" to find closest point when current distance +/- set point is not equal to value when object found.


thanks for the information

Clarkden
RC Hobby Shop
clarkden offline
Newbie
Newbie
Posts: 4
Joined: Sat Sep 25, 2010 2:27 am


5 postsPage 1 of 1
5 postsPage 1 of 1
cron