Robot Main.vi

[Sauce]

Our instructor has told me to find a document specifically stating that we need to use the Robot Main.vi within competition without being disqualified. He thinks we should be able to run our robot without it with a VI for teleop and a VI for Autonomous.

anyone care to refute this claim?

[bladetech932]

you don't (by rules) need to use it but you will have to build a program to call both telop and autonomous without stopping the program which is what robot main does.
I sugest you not make a different program, just modify the robot main for example get rid of every thing you don't use, which will also increase the data you can use

[Greg McKaskle]

Perhaps the instructor is familiar with FTC where the FMS launches and aborts top level programs. For FRC, it doesn't do this. It is the team's job to start their own program and to pay attention to the control packets. To assist, the WPI libraries and sample code help to schedule code according to the packets.

It is not required to use RobotMain, and the elements for constructing it are in the palette as well. In reality, you don't even need to modify RobotMain, but instead need to modify the Team Code folder. For example, Begin.vi is where you init any I/O you will use and store the references. Teleop is where you use the references and input from joysticks and driver station I/O to update the motors and outputs. Autonomous Independent is what I'd recommend you start with since you don't need to worry about the protocol. The framework will start and stop the VI for you.

Build dashboard data is where you can decide what to send to the dashoard. Finish is where you can release the I/O refnums.

Greg McKaskle

[elmer_fud]

I don't think you have to use Robot Main either but I would recommend you stick with the outline that is supplied unless you are EXTREMELY good at programming. If you start developing your own framework you have to make sure to do things like set up the watchdog and driver station properly. If you don't set up the watchdog properly you could run into problems with the robot not running or not stopping when you press the E-stop button. If you E-stop button doesn't work correctly I think you would be disqualified for safety reasons. My recommendation would be to clean up robot main and remove or empty out things that you are not using. For example if you are not using a camera I would disable it and remove it from all the Sub-VI's. I would then make a new dashboard that did not have a video patch thru.

[jhersh]

Originally Posted by elmer_fud

If you start developing your own framework you have to make sure to do things like set up the watchdog and driver station properly. If you don't set up the watchdog properly you could run into problems with the robot not running or not stopping when you press the E-stop button. If you E-stop button doesn't work correctly I think you would be disqualified for safety reasons.

If you don't set up the watchdog correctly, you may not be able to get your robot to drive, but it can always be E-Stopped. There is a separate watchdog that teams have no control over that responds to the E-Stop command. Nothing you can screw up in your code will make it fail to E-Stop.

[Greg Hoagland]

Originally Posted by Greg McKaskle

In reality, you don't even need to modify RobotMain, but instead need to modify the Team Code folder.
Greg McKaskle

I'm a relative newbie to Labview and was thinking that our team wouldn't need to modify RobotMain. Weve only been modifying code in the Team Code folder however we ran into a problem today in our first 3 matches in the San Diego regional today that caused our Robot to immediately stop when it switched from Autonomous mode to TeleOp mode.

The problem is as follows: Within RobotMain, the conditional terminal in the while loop is wired to the output of the case structure whose selector is the Robot Mode. It turns out this wire into the conditional terminal is undefined for all Robot Modes except "FINISH". I may be wrong, but it seems to me that unless RobotMain is modified to explicitly define the value on this wire for all Robot Modes, a robot may randomly stop. Our team made this change after the 3rd match, and we were able to complete the remainder of our matches successfully.

I was very surprised we hadn't run into this problem in any of our pre-regional testing but I'm guessing that this undefined boolean wire value takes on a random memory value and again I'm guessing that most memory is zeroed out so this undefined wire value is probably FALSE most of the time so the while loop in RobotMain doesn't stop prematurely.

Does it seem reasonable to others that RobotMain could randomly stop if it isn't modified to fix this issue?

If this is an issue it would probably be good if NI could put out a new LabView release to fix this becaue I bet a lot of teams aren't fixing this. I checked one other team at the SD regional and they were running RobotMain unmodified.

[Vikesrock]

Greg,

If you right click on the tunnel you refer to, you will see the "Use Default if Unwired" option is checked. The default value for the tunnel is False.

Labview will not allow you to run code that has a tunnel that is not defined in all cases. If you uncheck the option I mentioned above, you will see the muddle of the tunnel turns white and the run arrow changes to broken.