Victor and Encoder Opens fail

[jross]

I've seen a weird problem where intermittently, several of the WPI Robotics Library Open commands fail. This occurs without any changes of the code, and both when deployed or running in ram. It only occurs about 1/20 times (it's happened once in a practice match, once in a real match, and a few times in practice.

I've attached our begin.vi, in case that might give any clues. All the hardware (IE WPI Robotics Library calls) is handled in begin, the missing sub-vis do other things.

In our case, it is a victor open (PickupMotorDevRef) and an encoder open (TurntableEncoderDevRef) that fails, although our other victor opens and other encoder opens work fine. It is always those two that fail, although they work 19/20 times

Since I figured out what was happening, I started grabbing all the error clusters, and if there is any error in any of the opens, display a message on the DS, which would prompt the driver that there is a problem and power could be cycled to the robot. This works, but it can be interesting trying to explain to the FTA that the robot has synched and everything looks good on the FMS, but the robot isn't working right and needs to be power cycled.

I noticed Team 45 posted on chiefdelphi about what might be a similar problem. And, a few months ago, Mike Dubreuil had a mysterious intermittant problem that caused his motor controllers not to initialize.

[Joe Hershberger]

That's strange indeed. It would be far more helpful if you could post what the errors actually are.

Also, as for power cycling, all you need to do is reboot from the Driver Station (hold all 3 buttons for about a second then press select for a half second)... then you don't have to go out on the field.

[heydowns]

I don't know that much about the base robot code templates for LabVIEW, but I've helped a number of C++-using teams this year who had a problem similar to this, pretty much only on the field and even then, intermittently.

In most cases, they were creating objects that used hardware resources in autonomous (enabled) mode and not cleaning them up (and re-initializing if needed) until teleoperated.

Most of the time this works fine because the field will do the published set of state transitions (auto dis->auto en->tele dis->tele en).

But, depending on various conditions, the control system will sometimes get sent in the sequence auto enabled->auto disabled->{match start}auto enabled->tele dis->tele en. The first 'auto enabled' is very brief and usually imperceptible with regards to actual robot movement. However, it is long enough for the autonomous execution to begin on the cRio.
Cleaning up resources on EXIT of autonomous allows for safe re-allocation if the robot is sent back into autonomous.

This wasn't just a problem with resource allocation -- lack of resetting autonomous state machines, etc were also problematic.

Anyway, my suggestion is to check that the victor and encoder creation (if that's the right LabView term ) are handled correctly if you end up doing auto enabled->auto disabled->auto enabled set of transitions.

[Joe Hershberger]

But, depending on various conditions, the control system will sometimes get sent in the sequence auto enabled->auto disabled->{match start}auto enabled->tele dis->tele en. The first 'auto enabled' is very brief and usually imperceptible with regards to actual robot movement. However, it is long enough for the autonomous execution to begin on the cRio.

This condition is possible if the robot is powered on before the driver station... as the driver station boots, it starts in practice mode and enables the robot (since the E-Stop button is not pressed, which to the driver station looks like a dongle switched to enable)... then the driver station gets a packet from the field management system (putting it in FMSMode) telling it to disable the robot and normal field control continues from that point on.

[heydowns]

This condition is possible if the robot is powered on before the driver station... as the driver station boots, it starts in practice mode and enables the robot (since the E-Stop button is not pressed, which to the driver station looks like a dongle switched to enable)... then the driver station gets a packet from the field management system (putting it in FMSMode) telling it to disable the robot and normal field control continues from that point on.

Yup, exactly. We saw a lot of programs that was not prepared to handle this over a few different regionals.

It is easy to test for at your home facility/in pits -- never reset your robot and do all the various possible state transitions (even ones you don't expect in "normal" operation) from auto<>teleop, enabled<>disabled.

(probably worth mentioning the safety hazard of a robot that is expected to be disabled but isn't.... this is one thing about the FMS<>DS that would be nice to have changed architecturally for next year. I know field management has been trying to run a "robots off until DS links" rule, but I know of at least one recent regional where this paradigm was totally not used)

[jross]

That's strange indeed. It would be far more helpful if you could post what the errors actually are.

Unfortunately, the WPI_Error.txt file is still on the robot, and it isn't back yet.

Also, as for power cycling, all you need to do is reboot from the Driver Station (hold all 3 buttons for about a second then press select for a half second)... then you don't have to go out on the field.

But that still causes a loss of radio communication, and delays starting the match.

I don't know that much about the base robot code templates for LabVIEW, but I've helped a number of C++-using teams this year who had a problem similar to this, pretty much only on the field and even then, intermittently.

In most cases, they were creating objects that used hardware resources in autonomous (enabled) mode and not cleaning them up (and re-initializing if needed) until teleoperated.

Most of the time this works fine because the field will do the published set of state transitions (auto dis->auto en->tele dis->tele en).

But, depending on various conditions, the control system will sometimes get sent in the sequence auto enabled->auto disabled->{match start}auto enabled->tele dis->tele en. The first 'auto enabled' is very brief and usually imperceptible with regards to actual robot movement. However, it is long enough for the autonomous execution to begin on the cRio.
Cleaning up resources on EXIT of autonomous allows for safe re-allocation if the robot is sent back into autonomous.

This wasn't just a problem with resource allocation -- lack of resetting autonomous state machines, etc were also problematic.

Anyway, my suggestion is to check that the victor and encoder creation (if that's the right LabView term ) are handled correctly if you end up doing auto enabled->auto disabled->auto enabled set of transitions.

We were very careful this year to only open hardware one place (begin.vi) and to make sure all the state machines were reset. We've been in the situation in the past where we've written it in such a way that it only works once, and wanted to avoid that this year.

This problem only occurs on power-up / reboot.

[jross]

That's strange indeed. It would be far more helpful if you could post what the errors actually are.

It happened again, the robot was powered up for the first time. I've attached the WPI_Error.txt which shows it doesn't like the distance per count for the encoders. The begin.vi is identical to the one I posted in the first post, and it still only happens very intermittently.

[Joe Hershberger]

It happened again, the robot was powered up for the first time. I've attached the WPI_Error.txt which shows it doesn't like the distance per count for the encoders. The begin.vi is identical to the one I posted in the first post, and it still only happens very intermittently.

The errors in the error file don't seem to be related to the problem. There is a bug in the encoder open that causes the DistancePerCount error to show up in the error log even when the error condition did not happen. It should have no impact on anything. There is no actual error. I think you'll find that you get this error all the time (when you use encoders).

Hmmmm... I wonder what this could be since there doesn't seem to be any clues from the errors file.

[jross]

Hmmmm... I wonder what this could be since there doesn't seem to be any clues from the errors file.

Would writing the text from the error clusters to a file help, when there is an error?

[Joe Hershberger]

Would writing the text from the error clusters to a file help, when there is an error?

Joe,

There is a case where that could help... the errors in the error.txt are only the errors that come from the library itself. Any errors that come from the lower level APIs are not put in that file. It's quite possible that the error is coming from a driver and not showing up there. Try your suggestion... log errors to a file (be sure to flush ) and let me know what you find.

-Joe.