Bot repeated dying at Regionals. Can someone review the code?

[kaszeta]

Team 95's robot repeated would die during autonomous mode. The bot would stop, the color LED would go out, and the radio would go offline until the RC was power-cycled (not even a reset).

We were not able to recreate this in the pit (even after getting permission to test with the radio), and replacing radio and cable didn't help.

During the Friday matches, an IFI representative first thought that it had to be a code error and helped us review our wiring (as did a few people from other teams). On Saturday, after being dead in the middle of autonomous, he followed up saying that it looked more like a problem with the master controller, and suggested an RC swap. However, of three different RCs loaned to us, the first two had issues (the first wouldn't accept code uploads and appeared to be an un-upgraded 2004 RC, the second showed the 8.2 Volt problem (with the default code!) mentioned in another thread, and the third finally worked properly, although our last match had passed by then).

I'm going to call IFI tomorrow, but I thought it might be good if I got another set of eyes to look at our code, since I can't see any issues there. The current code we're running is Kevin's frc_gyro code (compiled to use an ADXSR300 instead of the the kit gyro), a PID controller to control rotation (so that the bot drives straight and controllably), and some basic mapping of inputs from controllers to pwms. No real rocket science here, and since the first tme our bot errored out, we don't even have any camera code, shaft encoders, or anything complicated like that.

However, since most teams haven't competed yet, I don't want to openly release the code (although most anything interesting has already been posted). But if your team has already competed, or you're willing to have some discretion with the code, and you're willing to look over the code to see if there is anything wrong, could you PM me or email me at rich@kaszeta.org? We're playing again at Palmetto, and would like our bot to actually function instead of sitting there motionless.

As I said, both our programmers and the IFI rep think it was a problem with our RC, but I'd like to make sure it's *not* a code error causing this.

Edit: By the way, we saw this problem with both the original FRC_library.lib *and* the updated version released the other day on the IFI site.

[Tom Bottiglieri]

We were having this problem in testing. The bot would die, and could not be fixed until a full power down occured. It took a bit to fix, but I can take a look to see if anything is wrong.

[chris31]

It looks like alot fo people are having this problem.

[X-Istence]

It is a problem with the CPU that is on the boards, as in it is an error in the silicone. IFI knows about the problem, as several others and myself have emailed them about this problem. The new libraries are supposed to fix this, but yet we got the same problem at the NJ regionals. Since we did not have a joystick on port 4, I added the following code to Process_Data_From_Master_uP, and to User_Autonomous:

if (p4_y != 127 || p4_x != 127 || p4_sw_top || p4_sw_trig) {
    while (1) { ; }
}

What this will do is cause a code error if there is any data on Joystick 4, as that means the data is all wrong. This helped us catch it one time when it happened again, before the match started

[gnirts]

Originally Posted by Tom Bottiglieri

It took a bit to fix, but I can take a look to see if anything is wrong.

How did you finally fix it?

Originally Posted by X-Istence

What this will do is cause a code error if there is any data on Joystick 4, as that means the data is all wrong. This helped us catch it one time when it happened again, before the match started

How are we supposed to use this? What's the point of causing a code error? (obviously I am missing something...)

Thanks in advance,
Robinson

[Eldarion]

While ours did not die completely, every now and then (actually about 50% of the time ), the autonomous_mode flag will be cleared for an instant and then reset, forcing the auto mode code to restart from the beginning. We are using the dongle, and the error does not appear to be in our (custom, not Kevin's) code. Has anyone else seen this?

We have not been able to test the new libraries, as we do not have another 2006 controller.

[BradAMiller]

Originally Posted by Eldarion

While ours did not die completely, every now and then (actually about 50% of the time ), the autonomous_mode flag will be cleared for an instant and then reset, forcing the auto mode code to restart from the beginning. We are using the dongle, and the error does not appear to be in our (custom, not Kevin's) code. Has anyone else seen this?

There was another team at BAE that had similar symptoms to yours - where they had different behavior off then field then on the field.

There was a "feature" in last years field controls that put the robots into Operator Control mode for a short time before starting Autonomous. I don't know for sure, but have heard that the problem is still there this year. There was some work put into WPILib and EasyC to try to make them work in this environment since they actually yank the program out of the Autonomous or OperatorControl functions when the field state changes.

I helped a team track down a problem that they believe was caused by this. They had a motor that would start moving to some position in Operator control mode. After the motor was started, the program then started running the autonomous code that wasn't checking for the motor position. So it ended up "running away" since there was no reason to check it - it wasn't supposed to be moving.

They ended up making a bunch of changes at the same time, but they thought this was happening to them.

You might want to verify that this isn't happening to you - if there are some variables that are being modified in operator control that your autonomous code is depending on not being changed, it could cause all kinds of problems that you would only see when on the actual field.

You could simulate this by starting your robot disabled & operator, then enable for a second, then change to autonomous. This can be done in the pits teathered.