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!)

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

[Mike Betts]

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

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]

Originally Posted by KenWittlief

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]

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

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]

Originally Posted by Mike Betts

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.

[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