Startup Delay, Effects Everyone?

[bomber7]

Originally Posted by bomber7

The cRIO works great, our code works, however even with default program code the cRIO seems to follow this time table. (Approximitly)

000s cRIO turned on.
040s Labview dashboard begins receiving data.** (As well as Driver station)
080s User-created code begins to run.

I am using the windriver development enviroment.

If I'm not mistaken an 80 second delay between the turn on of a robot and the start of its usefulness will prove too long for the way we normally do competitions. It also makes testing a real pain.

Is this problem widespread or are we just having some kind of funny bug?

Yes I quoted myself >.>

I want to know if everyone is having this problem or just me? Its pretty ridiculous to have to wait 80 seconds before the robot becomes responsive.

I'm using windriver, but if the problem's part of the cRIO it could affect lab view too.

If your having this problem please, please say so. If not, I would like to know that too.

**Clarification, at 40 seconds, by the dashboard begening to recieve data, I mean the mode displays disabled, and the status says "connected"
I know that the dashboard is always recieving data as long as the cRIO is turned on.

[dani190]

yep we see this issue also, i wonder what they will be doing about it...

[bomber7]

Originally Posted by dani190

yep we see this issue also, i wonder what they will be doing about it...

Thank God! Will sort of... Its a bad issue, I guess its like finding out your not the only one with a fatal disease......

[nathanww]

The delay is caused mostly just by the fact that the control system is so much more complex than last year's--for one, the cRio has an actual operating system. There's also a lot more paralell processing going on, which means that in order for the robot to perform all its functions, all the coprocessing devices need to be booted up, which for my team is the camera, bridge, and DS, in addition to the cRio.

I have been wondering how they're going to manage this at competitions--at the minimum, we'll be wating for the (significant) amount of time it takes the DS to boot since it'll be off until we plug in the competition port.

[RyanN]

Not sure if this is the case, but I think a lot of the wait is due to the Linksys router. At competition the router will remain on.

[EHaskins]

With the DS on with two joysticks, it takes ~30sec for our system to become responsive. I've never tested with the DS/router off, but those both take some time to load. I can believe that from a totally cold boot of everything ~60sec will be normal.

[whitetiger0990]

Ours starts up in 30 seconds.. haven't timed the bridge connecting..

It's gotten to the point where I tell people to not turn it off unless extremely important D=

[Vikesrock]

I have now read and/or heard quite a few people saying that the startup time will affect the way matches are run at regionals.

Maybe I'm just misremembering, but I don't think it will be that big of a deal. Introductions take about this long anyway. It just means that it is even more important than before that everyone remembers to turn their robot on before leaving it on the field.

[bomber7]

Will even if it only overflows 5s into auto, that leaves only 10s of normal operation.

Its important that they have some kind of tracker that makes sure all the robots become responsive before the match is started

[Vikesrock]

Originally Posted by bomber7

Will even if it only overflows 5s into auto, that leaves only 10s of normal operation.

Its important that they have some kind of tracker that makes sure all the robots become responsive before the match is started

The Field Management System (FMS) software keeps track of a number of robot readiness parameters so they can make sure that all robots are properly connected and ready to go before the match is started.

[DtD]

I noticed this today on our bot, after looking into it, it seems that it is because of the Gyro's init code (otherwise it starts up pretty fast!) if you have alot of sensors being constructed that you aren't using, then try deleting them.

~DtD

[Jared Russell]

Our machine has 5 encoders and a gyro and boots in 30 seconds or less (assuming the driver station and router are online).

For those with long boot times: if you use a null-modem cable, do you see any errors or failed assertions during startup? Maybe these could be slowing you down?

[repairmanray]

During beta testing, it was discovered that the boot time was related to the number of joysticks that were connected. Not sure if that's still the case with the official control system.

DS boot time, that is...

[Sentient]

Originally Posted by nathanww

The delay is caused mostly just by the fact that the control system is so much more complex than last year's--for one, the cRio has an actual operating system. There's also a lot more paralell processing going on, which means that in order for the robot to perform all its functions, all the coprocessing devices need to be booted up, which for my team is the camera, bridge, and DS, in addition to the cRio.

If you plug in a serial cable and read the debug output from the cRio in hyperterminal, you can see all the start up processes the thing is running even before it takes a look at user code. This is really a whole new animal from previous years.

[pitzoid]

Originally Posted by Vikesrock

The Field Management System (FMS) software keeps track of a number of robot readiness parameters so they can make sure that all robots are properly connected and ready to go before the match is started.

This is correct, FMS won't even let the scorekeeper start a match unless the DS is reporting to FMS that the robot is ready to start (which means you're synced up and ready to go) unless the scorekeeper bypasses you which will keep your bot from running. We'll know by the end of this weekend (Suffield) how boot times will effect student tournaments. FTA training last weekend rotating 12 robots in and out of the arena seemed to have no problem with the boot times, but like mentioned, if someone forgets to turn on their robot or some other issue like you guys accidently hit your estop which will require you to power cycle the robot to clear the estop, those kinds of things will eat up tournament time.