Robot Jumping on Power Up

[Mike Betts]

Since we upgraded our RC to the V10 Master Code, we have noticed a problem with all PWM's jumping to full on (254) for a fraction of a second after power up.

This problem does not appear with a robot reset while power is on... Just once every power up.

Is anyone else seeing this or, even better, figured out what causes it?

If we are the only ones, we may have a defective controller...

Regards,

Mike

[KTorak]

Our robot jumps when we reset it after downloading code to it...the only way we have stopped it is to just make sure its disabled when you do it.

[team222badbrad]

Last year our arm would do this...

On nearly ever start up the robot would jump the drill motors powering our arm and this created a short grinding noise from the sprocket jumping the chain....

I think this only happened though when the IO was being powered from the RC with the tether?

We never really sought out a fix; we just laughed ever time it happened ;)
(We considered the grinding noise to be the tigers ROAR!) :ahh:

It probably has something to do with the firmware/software in the RC?

[Mike Betts]

Our robot jumps when we reset it after downloading code to it...the only way we have stopped it is to just make sure its disabled when you do it.
The problem is how to disable... If you disconnect a tether or power down the OI at a competition, your radio is active and can/will interfere with robots on the field.

JMHO,

Mike

[kjohnson]

We had a problem with our robot wanting to launch off of our cart when we turned it on - but as long as someone is just holding it it won't go anywhere. 1610 also had this problem (I helped them with a battery change in finals).

[devicenull]

We aren't having this problem.. I hear no motors moving unless we tell them to

[CmptrGk]

im glad to hear that this was not just a problem with our robot. but the only differnece is that it has always done it. even with the factory firmware. i thought that it was a problem in my code, that was hiding from me. well mabey there will be a fix by nationals, even though this is not a big problem it is still a problem.

[KenWittlief]

If you have a competition port adapter connected you should power up in 'disabled' mode

I would have someone look at your code. It sounds like maybe you are using some motion smoothing algorythm, and one of the variables gets cleared to zero on powerup (instead of the last commanded or last output value)

in otherwords, you may have variables in your code that are not correctly initialized, so the first time through the loop you get an unexpected output.

PID control can be especially tricky to initialize, there may be several variables that would have to be initalized to the right value to get a 127 output on the first pass through the loop.

[kjohnson]

I would have someone look at your code. It sounds like maybe you are using some motion smoothing algorythm, and one of the variables gets cleared to zero on powerup (instead of the last commanded or last output value)

in otherwords, you may have variables in your code that are not correctly initialized, so the first time through the loop you get an unexpected output.
We do have one, so this may be the problem. It is not a "critical" problem that really needs to be fixed - its more of a nuisance.

[bombadier337]

We only had this problem when tethering the bot. It never happened when using our radio modems during practice, but every time we plugged in the tether it jumped. I figure that's just what happens when the PWM signal generator is initialized or something.

[probizzle]

Hmm,
I'm surprised so many people have the same problem.

I only had it once, and that was when I forgot to initialize all my pwms to 127. Because as unsigned chars, everything was initialized to 0, and that means that that motor was moving.
I would urge you to make absolutely sure that you initialize your pwms, because (most of the time), the robot does only what you tell it to do.

[Mike Betts]

If you have a competition port adapter connected you should power up in 'disabled' mode

I would have someone look at your code. It sounds like maybe you are using some motion smoothing algorythm, and one of the variables gets cleared to zero on powerup (instead of the last commanded or last output value)

in otherwords, you may have variables in your code that are not correctly initialized, so the first time through the loop you get an unexpected output.

PID control can be especially tricky to initialize, there may be several variables that would have to be initalized to the right value to get a 127 output on the first pass through the loop.
Ken,

I have this problem on PWMs which I do not use... If I attach a servo to them they jump after power up and then go to the "initialized" value of 127. My code (other than initialization) does not reference them but they will jump upon the next power up just the same...

[Dan9874123]

hmm, either A: it's a problem in user initialization and you need to check those values, or
B: it's a bad RC and you need to send it in for repairs, contact US FIRST about it. Although it doesn't prevent the RC from functioning properly it can be a serious safety hazard, or potentially damaging the robot.

[Dave Flowerday]

If I attach a servo to them they jump after power up and then go to the "initialized" value of 127. My code (other than initialization) does not reference them but they will jump upon the next power up just the same...
Mike, are you certain that all of your output variables have been initialized before you first call putdata()?

I imagine you've tried this already, but have you checked to make sure that the data you're getting from the OI is OK on the first loop? I vaguely recall someone saying that on the first loop the data they got from the OI was junk and that they had to ignore it to get rid of the problem.

[eugenebrooks]

Since we upgraded our RC to the V10 Master Code, we have noticed a problem with all PWM's jumping to full on (254) for a fraction of a second after power up.
Mike

We did not see this problem when we upgraded to V10 at the Sac regional.

If you are not using the custom pwm outputs, and have the default call that sets them up at the end of the main loop, try commenting this code out. We have had strange behavior, in the past, when this call was left in and taking it out is standard procedure at this point.

Another thing for you to check is that you are running the patch that was published by IFI late in the build period last year. Without it, you can get bad effects upon startup. If you started with this year's default code, you would have this patch.

If you resolve the problem, please post the resolution.

[Mike Betts]

Mike, are you certain that all of your output variables have been initialized before you first call putdata()?

I imagine you've tried this already, but have you checked to make sure that the data you're getting from the OI is OK on the first loop? I vaguely recall someone saying that on the first loop the data they got from the OI was junk and that they had to ignore it to get rid of the problem.
Dave,

From the user initialization:

void User_Initialization (void)
{
rom const char *strptr = "IFI User Processor Initialized ...";
Set_Number_of_Analog_Channels(SIXTEEN_ANALOG); /* DO NOT CHANGE! */
/* FIRST: Set up the I/O pins you want to use as digital INPUTS. */
digital_io_01 = digital_io_02 = digital_io_03 = digital_io_04 = INPUT;
digital_io_05 = digital_io_06 = digital_io_07 = digital_io_08 = INPUT;
digital_io_09 = digital_io_10 = digital_io_11 = digital_io_12 = INPUT;
digital_io_13 = digital_io_14 = digital_io_15 = digital_io_16 = INPUT;
digital_io_17 = digital_io_18 = INPUT; /* Used for pneumatic pressure switch. */
/*
Note: digital_io_01 = digital_io_02 = ... digital_io_04 = INPUT;
is the same as the following:
digital_io_01 = INPUT;
digital_io_02 = INPUT;
...
digital_io_04 = INPUT;
*/
/* SECOND: Set up the I/O pins you want to use as digital OUTPUTS. */
// digital_io_17 = OUTPUT; /* Example - Not used in Default Code. */
/* THIRD: Initialize the values on the digital outputs. */
// rc_dig_out17 = 0;
/* FOURTH: Set your initial PWM values. Neutral is 127. */
pwm01 = pwm02 = pwm03 = pwm04 = pwm05 = pwm06 = pwm07 = pwm08 = 127;
pwm09 = pwm10 = pwm11 = pwm12 = pwm13 = pwm14 = pwm15 = pwm16 = 127;

...

I have not changed this at all (even though I now realize that the Victors require a 132 for a true neutral, 127 still works)...

Mke

[MikeDubreuil]

I have not changed this at all (even though I now realize that the Victors require a 132 for a true neutral, 127 still works)... I did not realize that! Can you explain why 132 is neutral? Thanks.

[Jack Jones]

Since we upgraded our RC to the V10 Master Code, we have noticed a problem with all PWM's jumping to full on (254) for a fraction of a second after power up.

This problem does not appear with a robot reset while power is on... Just once every power up.

Is anyone else seeing this or, even better, figured out what causes it?

If we are the only ones, we may have a defective controller...

Regards,

Mike

We had a similar problem. Fix was to calibrate Victors.

[Mike Betts]

I did not realize that! Can you explain why 132 is neutral? Thanks.
Mike,

See the data at the beginning of this thread (http://www.chiefdelphi.com/forums/showthread.php?t=31903). I confirmed the data by experiment. The Victor has a zero output when given PWM values of 125 to 138 (mean 132).

A lot of the referenced thread goes into what might be causing the problem. I do not know why the Victors are non-linear. IFI claims that that they are linear (see this (http://www.ifirobotics.com/forum/viewtopic.php?p=402#402)) but this assertion is not backed up by experiment.

I have attached my data, taken with this year's kit frame, gearbox, CIM motors and wheels using the kit Hall effect sensors counting sprocket teeth with the frame on blocks (free speed except for bearing and gear friction).

However, this is getting off topic...

Regards,

Mike

[Mike Betts]

We had a similar problem. Fix was to calibrate Victors.
Jack,

This is seen with a servo attached to any PWM output. It is not a Victor problem...

Regards,

Mike

[Joe Johnson]

...snip...
I do not know why the Victors are non-linear. IFI claims that that they are linear (see this (http://www.ifirobotics.com/forum/viewtopic.php?p=402#402)) but this assertion is not backed up by experiment.

I have attached my data, taken with this year's kit frame, gearbox, CIM motors and wheels using the kit Hall effect sensors counting sprocket teeth with the frame on blocks (free speed except for bearing and gear friction).

However, this is getting off topic...

Regards,

Mike Mike,


Continuing your off topic comments...

I think I have an explanation for the data you have and it is consistent with IFI's claim of linear PWM output.

In my day job, we were breaking gear teeth on an actuator when the actuator was lightly loaded. No problem, we thought, we will just PWM the motor input and slow the actuator down. To our surprise, unless we got to very low PWM values, the free speed of our actuator stayed pretty much constant with respect to PWM value (we generated a chart very like the one you have shared with us).

Here is what we think we understand now: It boils down to the fact that we THINK that Vmotor = Vbatt X (PWM %) but that is only an approximation and it does not always hold true, especially if the PWM is the type that switches between Vbatt and OPEN CIRCUIT*, as my actuator driver and Victors do.

This is what happens as best as I can explain it. During the ON pulse, the motor accelerates (unless it is at its Vbatt Free Speed). During the OFF pulse the motor just coasts (recall that the motor is lightly loaded and that Newton's Laws apply: objects in motion remain in motion unless something slows it down). So... ...over successive ON pulses, the motor keeps accelerating until it reaches the Vbatt free speed.

The approximation of Vmotor = Vbatt * (PWM %) is much better for stall torque by the way.

Comments?

Joe J.

* There are other PWM types. For example the H-bridge could switch between Vbatt and Dynamic Brake (by holding both motor leads to Vbatt or both to Ground). Another example is that the H-bridge could switch between Vbatt and -Vbatt (in this case "off" is a 50% duty cycle which hits the motors with Vbatt for half the time and -Vbatt for half the time)

These other driver schemes are not as crazy as they may seem at first.

In fact, based on my non-FIRST experience with these types of drive schemes, I STRONGLY URGE IFI to offer these drive methods to FIRST teams in the future. They are useful in 2 ways. #1 If used for drive motors, the robot acts much more like a driver is commanding "speed" rather than commanding "gas" so the robot is easier to drive. #2 if used for large robot arms, the arms are orders of magnitude easier to control.

On the down side, they do pound more heat into the FETs but I'm an M.E. not a E.E. ;-) Bottom line, they make for well behaved robots. We should use them, even if they do stress the Victor a bit more. In my opinion, the Victors have the design margin in them. JJ

[KenWittlief]

presently you need to create a closed loop feedback control system to have your commands correspond to 'speed' instead of torque.

Im not sure closing the bridge would really map directly to speed- it sounds too easy to be true :^)

an out-of-the-box motor 'speed' controller from Victor would be super. I think it would have to measure the back emf and close the loop on itself.

[Joe Johnson]

presently you need to create a closed loop feedback control system to have your commands correspond to 'speed' instead of torque.

Im not sure closing the bridge would really map directly to speed- it sounds too easy to be true :^)

an out-of-the-box motor 'speed' controller from Victor would be super. I think it would have to measure the back emf and close the loop on itself.
I do not mean to imply that driving via an H-bridge that switches between Vbatt and Dynamic Brake takes the place of a feedback loop.

What I AM saying is that whether you are driving a robot via open loop or closed loop the job is considerably easier in the case where you have the H-bridge configured in this way.

I do not have time right now to explain, but essentially this drive circuit effectively adds a term to the dynamic equations that helps to stabilize velocity of the motor.

Joe J.