Weirdest problem in autonomous mode.
 

Hey, I wanna share a problem I had a few days ago, at the Israeli reigonals. When we tested the robot's autonomous code, before sending it, it worked fine, although I tested it only when debugging. When we got to the competition I discovered a very weird problem. It took me a long to figure what's wrong, but basically this is it: When the code comes across the first "Arcade Drive" vi, but only on first run, on autonomous period, and if the code is not debugging: it stop the code (and the robot) untill the timer on the DS reaches 20 seconds. when it reaches 20 seconds, the code goes on as if nothing happend. Unfortunatly, I understood this only near the end of the competition, so we didn't a working autonomous code most of the competition. To fix this, I unbundled the drive object to a four motors array and used the "Set Motor Value" vi for each of them every time I wanted to run the motors (it was only forward and backwards).

Does anyone have any ideas why something like this could happen?

Re: Weirdest problem in autonomous mode.
 

Could be the Safety vi is being tripped in autonomous.
It depends on how your code is written.
You should get a "takes too long" message on the Driver Station if this is the case though.

Re: Weirdest problem in autonomous mode.
 

I do recall seeing a message saying RobotMain is taking too long, but it also said it might be because the vi has a lot of code in it. Is this what you're talking about?

Re: Weirdest problem in autonomous mode.
 

Yes, if you get the message it means your main drive motors were shut down by the system.
If it's causing you problems in autonomous, then the message will appear at the beginning or during autonomous.

Re: Weirdest problem in autonomous mode.
 

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.

Re: Weirdest problem in autonomous mode.
 

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.

Re: Weirdest problem in autonomous mode.
 

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?

Re: Weirdest problem in autonomous mode.
 

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?

Re: Weirdest problem in autonomous mode.
 

Itamar,

Can you post an image of your code?

Re: Weirdest problem in autonomous mode.
 

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

Re: Weirdest problem in autonomous mode.
 

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.

Re: Weirdest problem in autonomous mode.
 

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