Weirdest problem in autonomous mode.

[PhilBot]

I really don't get this new "safety" code. Meaning... I don't know how to use it.

Is it like the WDT, do we need to feed it? How often?

How do I bypass it (I trust the FCS to stop me)?

Not knowing how it makes my code SAFE means it probably isn't.

Is there a write up somewhere?

Phil.

[Mark McLeod]

Safety Config Tutorial.pdf

It's just like the Watchdog in concept, but now hidden within specific LabVIEW FRC palette vi's. I'm also not sure it enhances safety, since if you don't understand what it's doing, then it'll probably get bypassed in an equally unsafe manner.

It's only implemented in the drive base Open 2/4 Motor vi's and subsequent uses of Tank/Arcade/Holonomic/Motors drive tied to that motor reference will feed the timer. It is not implemented in individual motor opens, such as for arm control.

The safety timer defaults to .1 second. If a call isn't made to Tank/Arcade/Holonomic/Motors with the timeout period, then the associated PWM outputs are set to zero.

It is easy to disable.
Simply double-click on the Open 2/4 Motor vi's you use in Begin.vi and you'll see "enable" right in the middle of the associated block diagram.
Just set it to "disable" to turn it off.

The concept behind the Safety Vi's is that during debugging/breakpointing or due to overly slow to respond code, the motors automatically get shut down, to keep the robot from running rampant.

It has the unfortunate consequence of invalidating a (what I consider a more efficient) style of programming and clutters up teaching basic programming concepts.

[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

[PhilBot]

Originally Posted by Mark McLeod

Safety Config Tutorial.pdf

Thanks for the link to the Safety Tutorial.
It was very helpfull.

Too bad that Safety Enable isn't brought out as a terminal in the Open2/4 Motor VI. I'd rather not edit the underlying library VI's. OK, I'm lying... I love editing the underlying VI's... but it gets me in trouble when updates ship

Phil.

[Joe Ross]

Originally Posted by PhilBot

Too bad that Safety Enable isn't brought out as a terminal in the Open2/4 Motor VI. I'd rather not edit the underlying library VI's. OK, I'm lying... I love editing the underlying VI's... but it gets me in trouble when updates ship

There is a safety config vi for robot drive that lets you enable/disable it.