Robot Jumping on Power Up

[Mike Betts]

Originally Posted by Dave Flowerday

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]

Originally Posted by Mike Betts

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]

Originally Posted by 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

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

[Mike Betts]

Originally Posted by MikeDubreuil

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

Mike,

See the data at the beginning of this thread. 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) 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]

Originally Posted by Jack Jones

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]

Originally Posted by Mike Betts

...snip...
I do not know why the Victors are non-linear. IFI claims that that they are linear (see this) 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]

Originally Posted by 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.

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.