Autonomous chooser not working when connected to the field

[scca229]

One thing to remember when setting static IPs that I didn't see in the thread is that the subnet mask is 255.0.0.0 and not 255.255.255.0 that you may be used to using elsewhere. This is classful addressing where the 10.0.0.0/8 RFC1918 network is being used.

[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....

[Tom Bottiglieri]

Originally Posted by mwtidd

Following 254's code from last year (https://github.com/Team254/FRC-2015), we implemented a web dashboard. The FMS whitepaper (https://wpilib.screenstepslive.com/s...fms-whitepaper) recommends you use 5800-5810 (web traffic leverages TCP).

The dropdowns in the stock dashboards have caused all sorts of headaches this year.

We ended up ditching the HTTP-over-field-wifi solution in favor of Network Tables as last year we had a bunch of connectivity issues on the field, especially when it came to Web sockets.

We now use a python->js gateway and our web app talks to a local server running on the laptop, which in turn talks networktables to the robot. It seems reliable. We also do some of the things mentioned in this thread like echoing the selected auto mode to another control and showing a robot generated timestamp to validate connectivity.

[mwtidd]

Originally Posted by Tom Bottiglieri

We ended up ditching the HTTP-over-field-wifi solution in favor of Network Tables as last year we had a bunch of connectivity issues on the field, especially when it came to Web sockets.

We now use a python->js gateway and our web app talks to a local server running on the laptop, which in turn talks networktables to the robot. It seems reliable. We also do some of the things mentioned in this thread like echoing the selected auto mode to another control and showing a robot generated timestamp to validate connectivity.

I had heard through the grapevine that you had changed your approach to use the networktables.

I really wanted to be able to leverage object serialization so I continued on the road you guys started down.

We were able to side step a lot of the FMS network issues by taking slightly different approach on the general network architecture. We have an onboard laptop that actually runs the server and acts as the middle man. That way the FMS doesn't interfere with communications between the Rio and the Auto Manager. Basically when a socket is opened we send the latest selected auto, so just declare the auto while you're in queue and you're should be good to go.

If the drive team needs to, they can change the auto from the DS via a web dashboard, and the server can broker the change to the Rio. As you suggested though, this can often be a headache because of the FMS wifi setup.

We actually leverage this same general architecture for generating trajectories on the fly and for vision processing as well. Being able to use Jackson or Gson for object serialization makes life sweet when programming in Java. It made re purposing the general idea for multiple purposes fairly straightforward.

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