[FTC]: Do Servo's reset during start up?

[ttldomination]

Hey Guys,

I was wondering if the Servos reset to their central position during start up. For any people that have gone to competition, like..when the robot is powered up, do the servos return to their zero position or do they remain where they are? Or is the current position set as the zero..?

I was wondering how that works.

Thankx

[wilsonmw04]

I believe that the servos try and set to zero at start up. You can change this with coding I think. I believe that's how we solved our problem. I'll check with my Programmers and have them post what we did.

[ttldomination]

Hm...It would seem to me that the current position at which the servos rest would be set to zero....

But i'm not sure.

[wilsonmw04]

If I remember correctly, the position the servo hits when you first supply power to the servo is the "zero" position. It's the same thing that's going to happen when it enter competition at the beginning of the game. It doesn't matter what position you put it into before the game. The zero is an absolute value and can't be changed. This can be useful when programing though. Zero will be the same position no matter where it was positioned before the start.

[emmell]

Is the value zero (0) or is the value 128? Servos can range from 0-255 so the center position would be 128, right?

[jbbjjbt]

Originally Posted by emmell

Is the value zero (0) or is the value 128? Servos can range from 0-255 so the center position would be 128, right?

Best I can tell all the servos head to center (127) whenever they first get power. This is with Labview. Does anyone know if it happens with RobotC?

Somewhere in the Q and A, it says you can send the servo's to a starting position before autonomous, so that you start in the 18" cube. The only problem with this is that the servos could be powered a long time waiting for the match to start.

[ShawnH]

Under RobotC, servos will not move after a power up. For us, we can easily move the servos while the robot is waiting for the auto-op to start. If you assign a value (0~255) in your program, servos would try to move that that location. From this point, a servo would always move to the location where the firmware told it to move to in the last loop.

In the newest RobotC templates, you can initialize servo values after a power up in your code. It does not have to be the center values.

[ttldomination]

Originally Posted by ShawnH

Under RobotC, servos will not move after a power up. For us, we can easily move the servos while the robot is waiting for the auto-op to start. If you assign a value (0~255) in your program, servos would try to move that that location. From this point, a servo would always move to the location where the firmware told it to move to in the last loop.

In the newest RobotC templates, you can initialize servo values after a power up in your code. It does not have to be the center values.

So, if we're using RobotC, the servos *DO NOT* center when powered up?

[PackersFan]

When we are powering up the servos head to zero after the first time we press a button. Anyone know why? This is an issue because this missaligns the servos. I think I have a workaround (make a button not in use align the servos, but I would prefer not to have to do that).

[ttldomination]

. This is what I have recently figured out.

The servos are naturally positioned and I believe they do automatically set to the 0 position when you start them. But inside the FTC template, there is a new section for initialize position. Inside that section try posting this code.

servo[servoA] = ServoValue[ServoA];

this should keep servoA exactly where it is. (Check my syntax, I don't think that's exactly it.)

[PhilBot]

Originally Posted by wilsonmw04

I believe that the servos try and set to zero at start up. You can change this with coding I think. I believe that's how we solved our problem. I'll check with my Programmers and have them post what we did.

When power is applied to the servo controller the servos get a momentary glitch which makes them twitch, but they are not held in that position.
Then unless you send a servo command the servo will just stay where you put them ( by hand ).
In labview, servo commands go from 1 - 255. A servo position of 0 means go to the last commanded position. Once you send a servo command, the servo goes there and holds that position. If you don't issue another command for a few seconds, the servo will power down.

[jbbjjbt]

Originally Posted by PhilBot

When power is applied to the servo controller the servos get a momentary glitch which makes them twitch, but they are not held in that position.
Then unless you send a servo command the servo will just stay where you put them ( by hand ).
In labview, servo commands go from 1 - 255. A servo position of 0 means go to the last commanded position. Once you send a servo command, the servo goes there and holds that position. If you don't issue another command for a few seconds, the servo will power down.

Do you agree that the momentary glitch at power up sends them toward the middle 127 (or 8) ?

This is enough to cause issues with buckets dumping or arms unfolding. Setting them to position ahead of time in autonomous may be bad if it takes a long time for the match to start.

[PhilBot]

Originally Posted by jbbjjbt

Do you agree that the momentary glitch at power up sends them toward the middle 127 (or 8) ?

This is enough to cause issues with buckets dumping or arms unfolding. Setting them to position ahead of time in autonomous may be bad if it takes a long time for the match to start.

As glitches are.... you shouldn't assume any particular direction of motion.

By definition, before the match starts, your software should not be driving the servos at all. Once you start your Auto program, all the outputs should be disabled until the program is "Enabled" by the FMS. This is definately true of the driver wheels, but also true of the servos (based on the current program templates).

The program inspection process is designed to test this. I don't know how critical they will be of servo motion when disabled, but if an inspector gets fussy, it may put your entire program in question.

Since the servo glitch occurs when YOU turn the 12V power on, then you are free to re-position it after the glitch has occured. Then when the program is "Enabled" it can be told to move to that same starting position, which should have the effect of just locking the arm in that position.

To try out all these scenarios, you should download the Field Management Software and run a "test" match. Goto the Software section of the USFIRST.org FTC page.

[jbbjjbt]

I have submitted a question to the official Q and A for clarification under the section Robot Inspection. I think based on question 6 the servos can be powered on before the match.

I agree that the "glitch" occurs when the servos are powered on. My experience is it always goes to or toward the center position. So maybe glitch is not the correct term.

I think if the servos are not continuously updated during the disable period between when you start the autonomous program on the NXT and when the FMS start the autonomous game period, that the servo will power down and the glitch will occur when the servos get power even if you set all the positions to zero. This is my experience.

[PhilBot]

Originally Posted by jbbjjbt

I have submitted a question to the official Q and A for clarification under the section Robot Inspection. I think based on question 6 the servos can be powered on before the match.

I agree that the "glitch" occurs when the servos are powered on. My experience is it always goes to or toward the center position. So maybe glitch is not the correct term.

I think if the servos are not continuously updated during the disable period between when you start the autonomous program on the NXT and when the FMS start the autonomous game period, that the servo will power down and the glitch will occur when the servos get power even if you set all the positions to zero. This is my experience.

I feel the need to clarify a few things here...

When I say "Power on the servos" I mean "Turn ON the 12V with the power switch". You have to do this before the match starts otherwise your robot will not move (as the same 12V runs the DC motors). This is when the "glitch" occurs.

Next, you say "if the servos are not continuously updated during the disable period..". OK, there really is no IF here. The program templates clearly show that the servos must be disabled if the program is getting a disabled state from the FMS (which IS the case between starting your autonomous program, and the start of the actual 30 second auto period). You can verify this yourself by downloading the FMS and trying it yourself

To disable the servos, you call the "FTC Move Servo" VI and set the "Enabled?" input to FALSE. This does not actually power down the servo, but it does stop sending pulses to it, which has the effect of shutting down the control loop inside the actual servo. This will cause the servo to droop if it's under load from your manipulator.

When the match begins, the FMS send an "Enable" state to the NXT which is interpreted by YOUR program to mean "Start the autonomous sequence". At this point you can start sending commands to the servo with the "Enaled? set to true.

Now, if the first position you send is a 0 then the the servo will probably jump to the middle, since "0" isn't an actual position. A position of Zero means go to the last commanded position (which in this case has never been done.).

Bottom line: only use Zero if you want to reissue a prior command (like in a refresh loop that doesn't know what the last command was).

I'd recommend you figure out where you want the servo to be when you start your autonomus sequence and send that position as soon as you get enabled. If you do that, there will be no "glitch" or any other unwanted movement at the start of teleop.

In our case, we assume that the servos that run our puck-picker-up will have drooped to the ground, so when auto is enabled we pick them up and keep them out of the way during auto.