[FRC Blog] Radio Silence

[Ginger Power]

Please don't pick another radio that has a 90 second reset time... watching robots die on the field this year was especially frustrating (and common) because you knew it would be for a large majority of the match.

[marshall]

Meh, not a huge deal either way. I'd like to see them jump to the next generation and get us more bandwidth though. Always a plus.

[Conor Ryan]

I hope the new radios get a back up power supply.

[tjf]

Originally Posted by Conor Ryan

I hope the new radios get a back up power supply.

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

[AdamHeard]

Originally Posted by tjf

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

[tjf]

Originally Posted by AdamHeard

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

From what I understand, the problem isn't the hardware, but the firmware on the device allowing the user to change the frequency outside of FCC regulation. For FRC to specifically request OpenMesh build an integrated and mandatory power backup would be complicated and costly. (imho)

The main problem, for me at least, is that the radio takes 90 seconds to boot... If they're working together on a custom FRC firmware why not make one that just boots faster and disabled unneeded features?

EDIT: Approximately 90 seconds, numbers were based on a match I watched and wasn't exactly counting with a timer. Take with a grain of salt.

[Alan Anderson]

Originally Posted by tjf

The main problem, for me at least, is that the radio takes 90 seconds to boot... If they're working together on a custom FRC firmware why not make one that just boots faster and disabled unneeded features?

I don't think I ever saw one take more than 60 seconds. 45-50 seconds was more typical. The rest of the delay some people are noticing is from the Driver Station sometimes taking upwards of 20 seconds to establish communication once the network connection is there. That appears to be a Windows networking thing.


It's my understanding that the bulk of the OM5-AP bootup time is in loading and initializing the built-in web server interface to the device settings. If that were removed from the firmware package, it could probably boot in less than 30 seconds. It would also take away a lot of flexibility for teams to tweak their network setup.

Given a couple of years with the same radio, I expect that the bootup time could be drastically slashed while providing teams with the appropriate tools to configure the device. That's probably not going to happen this year, though.

[Thad House]

One thing I wonder is that if when you configure the radio for field use, maybe the web dash could be disabled. There's no way anyway into the radio after it's been programmed without resetting it, so in competition mode that most likely would not be an issue. Especially as the firmware programmer and team flasher would work anyway without the dashboard.

[GeeTwo]

Originally Posted by Conor Ryan

I hope the new radios get a back up power supply.

Originally Posted by tjf

Pretty sure that'd conflict with R31, as the only exception I've seen is a device that needs a battery to function and will not without it, eg. a smartphone used for vision (like 254).

Otherwise, I'd have stuck a capacitor on the radio to make sure it stays on in the event of a brown-out.

Originally Posted by AdamHeard

If FIRST is working with someone to spec a radio, I'm sure they would allow themselves to write rules that made it legal.

Last year's R31 exception to the main battery read:

Additionally, batteries integral to and part of a COTS computing device or self-contained camera are also permitted (e.g. laptop batteries, GoPro style camera, etc.), provided they’re only used to power the COTS computing device and any peripheral COTS USB input devices connected to the COTS computing device and they are securely fastened to the ROBOT.

So, even with the same rule, a battery integral to the radio in its COTS state would have been legal. All they'd have to do is not disqualify it in a blue box or Q&A by deciding that the radio was something other than a computing device.

[notmattlythgoe]

Originally Posted by GeeTwo

Last year's R31 exception to the main battery read:


So, even with the same rule, a battery integral to the radio in its COTS state would have been legal. All they'd have to do is not disqualify it in a blue box or Q&A by deciding that the radio was something other than a computing device.

Or we could just go with the fact that R31 currently does not exist for the 2017 season and does not matter in this discussion...

[marshall]

Originally Posted by notmattlythgoe

Or we could just go with the fact that R31 currently does not exist for the 2017 season and does not matter in this discussion...

Are you saying "change is coming"?

[notmattlythgoe]

Originally Posted by marshall

Are you saying "change is coming"?

[PayneTrain]

[MrRoboSteve]

No question that boot time is a big downside of the OM5P-AN. It's ~60 seconds, compared to ~25 seconds for the previous d-link radio.

Considering the optimization target "number of seconds of robot-match time when the robot sat there unable to communicate", it is far superior to the d-link.

[tjf]

Originally Posted by Alan Anderson

I don't think I ever saw one take more than 60 seconds. 45-50 seconds was more typical. The rest of the delay some people are noticing is from the Driver Station sometimes taking upwards of 20 seconds to establish communication once the network connection is there. That appears to be a Windows networking thing.


It's my understanding that the bulk of the OM5-AP bootup time is in loading and initializing the built-in web server interface to the device settings. If that were removed from the firmware package, it could probably boot in less than 30 seconds. It would also take away a lot of flexibility for teams to tweak their network setup.

Given a couple of years with the same radio, I expect that the bootup time could be drastically slashed while providing teams with the appropriate tools to configure the device. That's probably not going to happen this year, though.

I hadn't taken that into account, mine was from when the robot stops moving to when the DS can move it successfully. Just for the sake of clarity, my total seems a bit larger, though roughly similar to the numbers you've seen. I wasn't exactly counting, it was during me watching a match I saw it happen and got my numbers, so take it with a grain of salt.

Though this is just my two cents, but if the device prioritized services (DHCP & Routing) above the webGUI, it'd help boot times, though this might be totally contrary to the way OpenMesh has the device configured.