Radio Probs

Technical Control System
1

Hello =)
Greetings from 714…

We had a couple of problems in the Regionals, and also in the Nationals in Atlanta, where it prevented us from doing what we needed to do…

A little heads up on what happened in Atlanta…

First Match … Robot Operated as expected , we got 3 rings and played good defense… Autonomous was Disabled … It did nothing on autonomous period…

Second Match … We forgot that we had the autonomous set to forward and the robot went off in reverse hitting the platform by drivers, and after it … we played a descent game but lost…

Third Match ( Where the problem started ) …
We voided the autonomous program, leaving it blank … and during the autonomous period, the elevator that elevates the arm running on a motor just started going and went all the way up ignoring the limit switch we had at the top, and jammed the claw, causing it to bend … which took us a whole match interval to fix…

Fourth match …
The autonomous was already OFF … we deleted it , and the autonomous sheet was BLANK … and it ran backwards during autonomous mode …

We asked couple of programers for other teams , and they said that the autonomous was blank, and it should not take any action while on the autonomous period…

However we heard that other teams had the same type of problems, and some suspected it could be the Radio …

We had the same problem in Trenton Regionals, and it ran on autonomous 3 times after program was blank, and arm would go up by itself on autonomous …

Anyone with similar problems?
Suggestions?

Thx,
Leandro Bergamasco
Team 714 Captain…

2

At the beginning of the season, many radio problems were reported, but they should be fixed now.

You need to test autonomous thoroughly. Refer to this document:


and make yourself a competition dongle. Then, reset the robot and put it in auton. Then turn auton off, reset the robot, and put it in auton again. Wash, rinse, repeat until you are sure it isn’t going to do anything. Then blame it on the radio.

And yes, I will try to help, but you need to test it well first.

JBot

3

Even when the robot is disabled it is reading input from joysticks.

IF your programmers removed the piece of code setting all the pwm outputs to 127 during autonomous mode those movements could be the result of the robot tryng to move while disabled.

If you need more info about this possible problem PM or e-mail me haskinseric@hotmail.com.

4

As the poster above said - you need to set all PWM’s to 127 to keep it from moving. Just put that in your autonomous loop and it won’t move at all.

5

I understand that it can try to move while set to neutral… but it is not set to neutral … and instead, has a clear program…
and yes we already reset the code…

6

I believe what he means is the opposite. The robot can move if it is NOT set to neutral.
In other words, if you don’t say pwm01 = pwm02 = … = 127 at the beginning of your autonomous, the robot can do whatever it wants.

7

It is also possible that you are not loading the right code into the robot. Either that or a little detail in the code is causing all this trouble. I’d triple check if the code you edited(directory) is the code you actually uploaded to the robot. This has happen to me a couple times and its a frustrating discovery.

8

Correct me if I’m wrong but I thought the user micro is passed idle values from the master when disabled or in autonomous? I know this is the case on the vex controller, I remember it being the case for the FRC controller as well though I haven’t used it in a few years. Otherwise autonomous could still take input from the user.

To add to what prograid said, you shouldn’t ever assume the initialization state of any variables in your program. This can lead to very bad problems, especially since a value of 0, a common initialization value, does not halt the motor! If you do not set the PWM values to idle you can have some very weird and dangerous results.

9

During autonomous and disabled modes the RC is still getting all of the inputs from the OI, but when the RC is disabled the master processor doesn’t create the PWM signals. That and the status flags in the code, is the only difference between the normal mode, autonomous, and disabled, modes.

Even if you are doing other things in autonomous it is a bad idea not to set the PWMs to 127.

10

Ah. I forgot that it still gets inputs, that was how we used to select autonomous modes before the match started. Thanks for the correction.

11

You’re half right.

When the robot is disabled, all joystick and switch input is passed along normally. It’s only the outputs that are suppressed. You can see this behavior using a Dashboard program.

In autonomous mode, the inputs are indeed forced to neutral (all joysticks at 127, all switches off). But if your program doesn’t do anything in autonomous, that can be a problem. Not doing anything means not shutting off things that were trying to move just before autonomous was selected. That’s what Eric and Tom are trying to warn about.

If you want to remove all autonomous actions, make sure to leave in the part at the beginning that sets all the pwm outputs to 127. Otherwise, a mistrimmed joystick or flipped switch can cause things to start moving and not stop until the teleoperated code starts running.

Here’s another piece of useful advice: if you have limit switches to protect mechanisms from moving too far, put the code to read the switches (and take action based on them) in the Process_Data_From_Local_IO() function, and call that function from within the autonomous loop. The default code only calls it when in teleoperated mode.

12

Also note, when you call it, call it towards the end of the autonomous loop or after all other functions have been called.