Weirdest problem in autonomous mode.

[beth_hadley]

Our team experienced an extremely similar error, and we too isolated the issue to the safety update to the config timer within arcade drive Although we initially tried to circumvent the issue by disabling the timer in Begin, this did not fix our issues in Autonomous. Our ultimate solution was to rewrite the WPI Robot Drive libraries without the safety update.

Autonomous is fixed, and now operates fine the first time through after reboot as well as every subsequent time.

We still use watchdog, although our timeout is 1 second rather than the default of 0.5 seconds.

Obviously, we have had a considerable amount of issues with the safety features provided, and I too feel that by eliminating them we are making our code more vulnerable. Any suggestions?, or can we be confident that there will be no issues at competition?

[Itamar]

I still don't understand. Why would the Safety vi be tripped during autonoumos and no during teleop?
Further more, why when I used the regular Set Motor Value vi did the Safety vi stop?

[Jon236]

Itamar,

Can you post an image of your code?

[Greg McKaskle]

The Safety feature, when enabled expects for the RobotDrive to be updated at least every 100ms. If it is not, say due to a breakpoint, a solenoid timer, an infinite loop in a subVI called from teleOp, then the Safety VI will set the motor speeds, on only the late motor speeds to 0. Unlike the WD, this will not shutdown the entire robot, only the outputs that aren't being updated by the code.

The typical way that this crops up in auto is for the auto code to set the motor speed once, then delay for some condition such as time. The general idea was to build an equivalent for the Delay and Feed which was in the WD palette last year. The block(s) for Update and Feed weren't complete in time, and weren't put into the palette. Even with them, more complex movements including other types of I/O is a bit difficult to write.

Greg McKaskle