My team has set up continuous servos that move as wanted. However, they don't brake (they just become limp at the deadband values). Is there any way to make continuous rotation servos brake like the standard servos do?

Tue Nov 22, 2011 10:52 am

magicode

Moderator

Joined: Tue Sep 14, 2010 9:19 pmPosts: 496

Re: Continuous Servo Braking

Continuous rotation servos do not have built in position detection. The potentiometer that is in regular servos has been removed so that these servos can continuously rotate. Thus, there is no way to have them stop at a specific value unless you add an encoder or potentiometer to the axle that the servo is controlling. If you are fine with doing this, then you can write code to have the servo "brake".

_________________sudo rm -rf /

Tue Nov 22, 2011 11:44 am

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1519

Re: Continuous Servo Braking

I always don't understand continuous servo. Aside from motor power, form factor, different motor controller etc, in terms of functionality, if I have a situation that requires a continuous servo, why not use a regular motor?We have an elevator on our robot, our mechanical team wanted to use a continuous servo at first but the programming team wanted to know the exact height of the elevator and of course be able to hold the height. So we decided to use a tetrix motor with an encoder. But then I can't really see what scenarios that must require a continuous servo that a regular motor cannot do.The only scenario I can see is if you just want to turn something continuously and you are running out of motor controllers (since motor controllers can only take two motors but servo controllers can take 6).Our robot also has a "conveyor" that picks up racquet balls that we just need it to keep running or stop. So it sounds ideal to use continuous servo. But we ended up using a tetrix motor on it too because we were worrying the continuous servo may not have enough power. So we really can't find too many scenarios that continuous servo is a must.

Tue Nov 22, 2011 2:02 pm

magicode

Moderator

Joined: Tue Sep 14, 2010 9:19 pmPosts: 496

Re: Continuous Servo Braking

Continuous rotation servos may be used when a motor is too heavy for the application, and it is not possible to bring motor power to the required spot on the robot using chain or linkages. That's pretty much the only reason I can think of besides the ones that you pointed out to use a servo in the FTC game. However, continuous rotation servos are great for hobby applications. They have basically the same functionality as a motor, and come with a motor controller and (usually) power regulator built in. All you have to do is supply power and send a pulse. This is why until last year, all VEX motors were actually continuous rotation servos.

_________________sudo rm -rf /

Tue Nov 22, 2011 3:03 pm

SergeantFTC

Rookie

Joined: Tue Nov 20, 2012 8:09 pmPosts: 35

Re: Continuous Servo Braking

Quote:

Continuous rotation servos do not have built in position detection. The potentiometer that is in regular servos has been removed so that these servos can continuously rotate. Thus, there is no way to have them stop at a specific value unless you add an encoder or potentiometer to the axle that the servo is controlling. If you are fine with doing this, then you can write code to have the servo "brake".

We are looking to have a continuous rotation servo that will be hand-initialized before the robot is turned on, and then when the robot turns on and the code runs, the servo will be held in its pre-set position (having the servo "brake"). I have two questions about this:

1.Would we need an external encoder on the servo for this?2.How would you go about writing code to "brake" the servo? Would you have to have the encoder measure how far away it is from where it should be and then apply power in the appropriate direction, using some kind of PID loop to keep it from overshooting?

Thanks.

Sat Sep 28, 2013 12:47 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1519

Re: Continuous Servo Braking

SergeantFTC wrote:

We are looking to have a continuous rotation servo that will be hand-initialized before the robot is turned on, and then when the robot turns on and the code runs, the servo will be held in its pre-set position (having the servo "brake"). I have two questions about this:

1.Would we need an external encoder on the servo for this?2.How would you go about writing code to "brake" the servo? Would you have to have the encoder measure how far away it is from where it should be and then apply power in the appropriate direction, using some kind of PID loop to keep it from overshooting?

Thanks.

Still don't understand what you are trying to do. If you are going to add an encoder to the motor, why not using the Tetrix motor. The servo controller doesn't allow you to add encoders. "Brake mode" is already the default but if you are going to hold the position of something heavy against gravity, brake mode may not be enough. You need to actively hold the position by doing PID control. So to answer your questions:1. Whether you need an encoder depends on what you are trying to do. If you are using servo, you can't add encoder to it. Brake mode is already the default mode. If you just want brake mode, you don't need to do anything.2. If you are going to do PID control on a motor, it must have feedback. In other words, you need an encoder or potentiometer. Servos have potentiometers built-in but continuous rotation servos do not and the servo controller doesn't support encoders. So in other words, if you want to do PID control on a motor, you must use Tetrix motors, not servos. To do PID control, you can either use the RobotC built-in PID support (i.e. nMotorEncoderTarget[]) or write your own PID algorithm. The difference is that RobotC built-in PID doesn't allow you to tune the PID constants. So there is no way to fine tune and prevent overshooting. Especially if you are doing PID control against gravity (e.g controlling an arm), the ability to tune PID is crucial.

Sat Sep 28, 2013 2:06 pm

SergeantFTC

Rookie

Joined: Tue Nov 20, 2012 8:09 pmPosts: 35

Re: Continuous Servo Braking

The primary reason we don't want to use a dc motor is that there is a tighter limit on how many we can use. I believe weight is also a big factor (I'm not on the mechanical subteam). I'm not sure if just brake mode would be enough or not, we would need to get a continuous servo to test that.

I was referencing what magicode said about encoders on continuous servos:

Quote:

there is no way to have them stop at a specific value unless you add an encoder or potentiometer to the axle that the servo is controlling. If you are fine with doing this, then you can write code to have the servo "brake".

He seems to think that adding some sort of potentiometer/encoder is possible. Is there any reason we couldn't attach a standard encoder to the servo and plug it into a motor controller encoder port that was otherwise unused? Sure, you'd have to reference the encoder as whatever motor it was associated with, but it would work, right?

How would using nMotorEncoderTarget[] work? Would we just set it to zero? Would that constantly monitor the motor for movement and compensate if necessary?

Sat Sep 28, 2013 2:43 pm

Ernest3.14

Professor

Joined: Sat May 18, 2013 1:24 pmPosts: 272Location: Olympia, WA

Re: Continuous Servo Braking

SergeantFTC wrote:

Is there any reason we couldn't attach a standard encoder to the servo and plug it into a motor controller encoder port that was otherwise unused? Sure, you'd have to reference the encoder as whatever motor it was associated with, but it would work, right?

How would using nMotorEncoderTarget[] work? Would we just set it to zero? Would that constantly monitor the motor for movement and compensate if necessary?

Yeah, I guess so. But be careful: when you read values from the encoder, it will be reversed (negative) if you reverse the motor in your "Motors & Sensors Setup". That cost us way too much debugging.

MHTS wrote:

I always don't understand continuous servo. Aside from motor power, form factor, different motor controller etc, in terms of functionality, if I have a situation that requires a continuous servo, why not use a regular motor?

In this particular case, I suspect it's due to the limitations of FTC, as magicode says. In FTC (unlike FRC), you are limited to 8 motors and 12 servos. So if you can get away with using servos, you can reserve the motors for the "heavy lifting". No use complaining about FTC's limitations with the protoboard and stuff here.

Another point: If you can get a protoboard and use cheaper encoders than the tetrix ones (which are End of Life and aren't sold by the manufacturer anymore), I would use those instead.

Yeah, I guess so. But be careful: when you read values from the encoder, it will be reversed (negative) if you reverse the motor in your "Motors & Sensors Setup". That cost us way too much debugging.

Thanks for the tip

Quote:

Another point: If you can get a protoboard and use cheaper encoders than the tetrix ones (which are End of Life and aren't sold by the manufacturer anymore), I would use those instead.

Oooh, good idea The Tetrix ones are EOL?? Does that mean they're getting replaced soon with new ones?

Sat Sep 28, 2013 4:26 pm

MHTS

Guru

Joined: Sun Nov 15, 2009 5:46 amPosts: 1519

Re: Continuous Servo Braking

SergeantFTC wrote:

Is there any reason we couldn't attach a standard encoder to the servo and plug it into a motor controller encoder port that was otherwise unused? Sure, you'd have to reference the encoder as whatever motor it was associated with, but it would work, right?

How would using nMotorEncoderTarget[] work? Would we just set it to zero? Would that constantly monitor the motor for movement and compensate if necessary?

In theory you could but in reality it depends on how you are going to do PID control. If you are using RobotC built-in PID control (i.e. nMotorEncoderTarget[]), the association of the Tetrix motor and its encoder is assumed. So if you put an encoder on the servo and then connect it to a Tetrix motor controller, the built-in PID will get totally confused.To use nMotorEncoderTarget, make sure whatever you want to control is at the resting position. Then you reset the encoder count to zero. Next, you set the nMotorEncoderTarget to the encoder position you want to go to and hold. Then you set the starting motor power. For example,

Code:

nMotorEncoder[motorD] = 0;nMotorEncoderTarget[motorD] = 1440/4; //assume 1440 clicks for one revolution, this gives you 90 degrees.motor[motorD] = 75; //starting with 75% power, PID will slow down towards the end.//// The following lines should be removed if you want to hold the position.// If you don't want to hold the position, the following lines will stop the motor when target is reached.//while(nMotorRunState[motorB] != runStateIdle) // while Motor B is still running:{ // do not continue}motor[motorB] = 0;

Since you cannot tune the PID constants, be mindful that you can still oscillate (i.e. overshoot) or the motor never reaches the target.

Sat Sep 28, 2013 5:05 pm

SergeantFTC

Rookie

Joined: Tue Nov 20, 2012 8:09 pmPosts: 35

Re: Continuous Servo Braking

Quote:

If you are using RobotC built-in PID control (i.e. nMotorEncoderTarget[]), the association of the Tetrix motor and its encoder is assumed. So if you put an encoder on the servo and then connect it to a Tetrix motor controller, the built-in PID will get totally confused.

(facepalm) Right. Of course.

Now, assuming we're using a DC motor, that code wouldn't do what I'm looking for. I want something that will constantly maintain a pre-set position.

Sat Sep 28, 2013 5:26 pm

Ernest3.14

Professor

Joined: Sat May 18, 2013 1:24 pmPosts: 272Location: Olympia, WA

Re: Continuous Servo Braking

If you're feeling adventurous, you might as well write your own PID loop. It's not that difficult, and you'll have control over the constants. As to the tetrix encoders, I wish FTC would stop mandating them. The absurd cost and difficulty of obtaining them is getting on my nerves. </rant>

Oh. Wait a minute. We've been using your gyro.h file for a few years now. Only we had to make a few changes, at the time it wasn't working the way we expected, it was turning the wrong way or something. Should I bother updating to the latest version of that? Do you know if any function names have changed or anything?

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum