AUTONOMOUS CODE! HELP!

[jhellr13]

It's coming down to the last hours. I need help with our autonomous code. Can anyone look at the attached code, and either give suggestions, or even better fix it for me?

Thank you all very much in advance

[jhellr13]

Here's the code

[j.cole]

I feel like all of those tunnels should have shift registers in there instead of tunnels. Other than that check all of your RefNum Gets.

[kamocat]

I don't think shift registers are neccessary here; the data in those refnums aren't changing, except perhaps the error state. However, if you would like to pass on the error every iteration, feel free.

One thing here that doesn't make sense to me is the use of the relay output. I see you have values such as -200 or even the iteration counter, wired to the relay state.
In fact, there are only four meaningful values: Off (0), On (1), Forward (2), and Reverse (3).
Anything outside that range will be coerced to the nearest meaningful value. That means -200 will be coerced to 0 (Off), and the iteration counter will go through all four states, and end on Reverse.

I also see that the only thing measured here is time. That being the case, there is a simpler way to write your code.

• Disable the timeout on the drive base.
• Use a "wait" function to wait the entire time something should execute.
• Compartmentalize each action with flat sequence structures, forcing sequential execution through data dependency.

I've attached an example of this.

[DavidGitz]

More issues with the original posted code:
-"Stand Still", "Stop Arm", "Stand Still", "Stop Arm", "Stop" will never finish (False constant wired to Stop Condition.
-"Lower Arm for 200 ms" will execute exactly once due to True constant wired to Stop Condition.

[DavidGitz]

Originally Posted by kamocat

I've attached an example of this.

I have a question concerning the Safety Config.vi Since you disabled this, what would happen if a User hits Disable from the Driver Station while this is executing? Or hits Emergency Stop? Just my ignorance showing, but we try to avoid configuring these vi's. I assume they will operate as normal as they are part of the System Watchdog, but I haven't used them at all so I am just checking.

[kamocat]

Every disable will still function.
The only difference is that the motors won't timeout from not being updated every 100ms.
In my attached code, I reenabled it at the end of autonomous.

[jhellr13]

Originally Posted by kamocat

I don't think shift registers are neccessary here; the data in those refnums aren't changing, except perhaps the error state. However, if you would like to pass on the error every iteration, feel free.

One thing here that doesn't make sense to me is the use of the relay output. I see you have values such as -200 or even the iteration counter, wired to the relay state.
In fact, there are only four meaningful values: Off (0), On (1), Forward (2), and Reverse (3).
Anything outside that range will be coerced to the nearest meaningful value. That means -200 will be coerced to 0 (Off), and the iteration counter will go through all four states, and end on Reverse.

I also see that the only thing measured here is time. That being the case, there is a simpler way to write your code.

• Disable the timeout on the drive base.
• Use a "wait" function to wait the entire time something should execute.
• Compartmentalize each action with flat sequence structures, forcing sequential execution through data dependency.

I've attached an example of this.

Thanks for the file. I hope this one will work. Now since build is done, i can concentrate on an autonomous code. In regards to the comments about enable and disable safety config, does it really matter which way i leave them?

[Greg McKaskle]

Safety Config adds a layer of safety, especially when debugging code. If safety config is turned on, it periodically checks to see if you have updated the output value. If several hundred milliseconds have elapsed and your code hasn't given an update, that is the cue for the safety manager to set the output for you -- to 0.

Do you want this on?
If your code to update the motors or RobotDrive will be executed in a loop or otherwise run more often than the safety timeout, then the safety VIs will allow you to hit a breakpoint in your code, accidentally crash a particular thread, write an infinite loop, and make many common debugging actions without the robot continuing on its way -- at least the safety config'ed outputs will be set to 0.

If you don't know how often your code is running, don't want to write it this way, aren't debugging anyway, or have really good bumpers and alternate safety practices, you can turn off the safety config. It is optional.

Greg McKaskle