Dear First: Please Give us a Ready Button!

[Arhowk]

IIRC, for C++/Java/Python teams, your robot won’t show up as ready until robotInit exits (try it – the DS will show ‘no robot code’ until robotInit exits). So if you blocked robotInit until your autonomous selection was made, then the FTA wouldn’t think your robot was ready, and probably wouldn’t start the match…

However, I don’t recommend doing this. If you mess it up or there’s an error in selecting your autonomous, then your robot will never connect, and I imagine that would be significantly worse.

This was something we did our last year that I was on the team. We remedied the “robot code fail” situation by having our compiler run twice, one with a flag that would disable this feature, than having a .bat that would swap from the normal code to the emergency code on the desktop in cTase the hotswapper failed for some reason.

The “success” scenario was done through a two way TCP pipe- the dashboard written in C++ had two pages- one took input and wrote data to a socket. That data would than be processed by the RIO and sent back to the dashboard. The second page of the dashboard was completely excluded from the first page and showed only the data received by the RIO to guarantee that was the data being shown by the RIO and a big ready button (well the start button on the xbox controller)

It was some cool stuff but obviously you need an incredibly skilled programmer to pull it off successfully.

[thatnameistaken]

EDIT AGAIN: I’ve lost track of who’s saying what, disregard this.

[bdaroz]

I think the piece that’s unclear is that we only calibrate on robot start up. We can (and will) calibrate manually closer to match start if there is an unusually long delay.

What we’ve found is that the percentage drift on our gyros is fairly low immediately after calibration, rises to a fairly low constant (something about 1 deg/90s), and tends to stay that way for quite some time (we stopped most of our measurements at about 5m)

Because we reset our 0-point at auton, and at the beginning of each command (eg spin robot 180deg), the drift really only matters from start of command to at most 15s of auto.

The hassle of constant, or “just before” auto calibration has too high a risk vs the reward for us.

[Anon10W1z]

How does that work if you’re calibrating when the match starts?

We start a calibration task (which is built using a Notifier) in disabledInit, and this task runs periodically until autonomousInit, which calls a method that stops the calibration task.