Testing pre_auton

We’ve tested the competition object’s autonomous and drivercontrol callbacks using “Timed Run” feature from the controller. However, the program is already running prior to the autonomous or drivercontrol function being launched. I don’t understand how to test pre_auton() properly. When doing a “Timed Run” or running from Robot Mesh Studio I can’t identify any way of delaying or otherwise controlling the launch of autonomous or drivercontrol like a Field Control System would. One or the other is launched right away (even with an infinite loop in pre_auton). We’ve resorted to commenting out the autonomous and drivercontrol to test pre_auton, but it makes me very nervous to send my team into a competition where they could not test things end-to-end like they really happen with a Field Control System.

Live-fire testing is usually done with the VEXnet Competition Switch, which is cheaper than the full field controller.

How are you trying to test the pre auton function? What does your pre auton function do?

I’m not sure the school has a VEXnet Competition Switch, I’ll look into it before next season. I tried roughly testing with the code at the bottom of this post. Technically, my test evolved from there, because the pre_auton was intended to keep some motors in hold to ensure robot appendages stayed inside the 18" cube prior to start. As such, it needed to be a thread that was killed by autonomous. Basically I replaced the call to pre_auton and did this instead:

 sys.run_in_thread(lambda: specialPreAuton.pre_auton())

automomous set a semaphore to signal specialPreAuton.pre_auton to die. This worked in my test, but as I feared it failed during an actual competition.

.
.

Do not adjust the lines below

Set up (but don’t start) callbacks for autonomous and driver control periods.

#competition.autonomous(autonomous)
#competition.drivercontrol(drivercontrol)

Run the pre-autonomous function.

pre_auton()
sys.sleep(30)
autonomous()
drivercontrol()

Yes, as you’ve seen, no motor command of any kind can be sent outside of the autonomous or driver control phases. This includes motor drive and motor brake commands. I would also expect, though I have not tested this recently, that requesting motor position or motor temperature would fail or return nonsense results. Motor commands are blocked at the VEXos level, there is no VRC-legal way to circumvent them.

A robot must start inside the 18 inch cubical volume entirely passively, without motor power. Most teams use some arrangement of rubber band and toggles tripped by wheel movement.

That’s unfortunate. This design was prompted by a failure of a rubber band type system you describe in the team’s prior competition.