Autonomous chooser not working when connected to the field

[gerthworm]

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

[MamaSpoldi]

Originally Posted by gerthworm

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

We use this same procedure as well (basically) and I agree that the feedback is essential to providing assurance to the drive team that it is functioning. However, when it was not working (due to the previously mentioned firewall issue and possibly fixed also by using static IP addressing) although they knew it was not working they could not really do anything to fix it.

[Greg McKaskle]

Regarding Flush:
I put flush in the LV implementation from the beginning so that camera code results or other potentially time sensitive values could have minimal latency. Rather than a write through where you are more likely to have inconsistent values, I chose to simply goose the timer and transmit all pending updates immediately instead of waiting for up to 99ms to transmit.

I didn't limit how often they could call flush and I'm not aware of an issue caused by it. As you mentioned, most values are updated at 50Hz, and that isn't much bigger than 10Hz. So if a user flushed each teleOp, they have only affected bandwidth by 5x at most. Also, only modified values are transmitted. I also allowed the user to specify how often their client or server waits to transmit updates. It defaults to 100ms and I haven't really heard of anyone using other values. For most NT stuff, 10Hz is fine.

By the way, the auto chooser for LV has its own rough edges. I'll document them here.

The selector presents all strings written to it within Begin.vi. Sometimes users don't find that initialization spot.
On selection, it writes the selection to the robot. But if the robot writes the value, it doesn't update the dashboard selector.
If the user builds a custom dashboard, they can change the default value of the selector, but the network table value isn't transmitted until it is changed. They would want to write the variable once anyway.

Hope to make it smoother next year.
Greg McKaskle

[cpapplefamily]

Originally Posted by gerthworm

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

This was the approach I was going to look at. Anyhow after some futher investigation the last Autonomous fail was not a software issue after all but more a series of events that lead up to this fail. Almost like the show why do plane crash? because a ground crew forgot to put the widgit in the gizmo on the last scheduled service 3 month prior.

In our case match one ran as expected but some time during the match the pinball Choo choo was hit and the escapement jammed.

Our Auto sequence is this:

1 Reset pinball if not on switch
2 open claw
3 close claw
4 lower wrist
5 drive under low bar
6 spin 90 deg
7 strafe to castle wall and raise wrist to fire angle
8 fire ball

Match 2 we observed the ball was never fired but it must had released and the cam came off the reset switch. (no step 8)

In the tie breaker step one never finished because it was jammed (observed in the pits when our tears finally dried). The turnaround time is so fast during elims there was no reset/test time in the pits.

We further proved this theory by looking at the driver station log files and observed the PDP currents for the Pinball, claw and wrist. In match one the pinball was already set on step 1 so no current resisted till step 8 on that channel.

In match 2 the pinball fired but is hard to tell if it rest

In match 3 we see when Autonomous starts the pinball channel goes high current, looks to trip the breaker, rest and autonomous is over.

If you have not ever look at these log fills ( I never have) do so look at a normal match, look at a match that did not go so well. I now know to plan if a command does not Finnish in a reasonable time it maybe best to time out and move on.

addSequential ( new my_Command , timeout)