Specifically I’m talking about the abysmal 4 Mb/s bandwidth limit imposed on teams during competitions. I don’t know when this limitation was put in place, but nowadays this is not a lot of bandwidth considering a 1080p video from YouTube can be anywhere from 8-10 Mb/s.
We have a functional 4 camera setup (1 for each side of the robot) that we plan on mounting to our robot very soon. It livestreams the video feeds over the network to a browser like in some vehicles’ backup cameras (
). With the advent of AprilTags, this can give us positional information no matter where we are on the field. This can all be done on-bot with a coprocessor, but we won’t be able to get live video feedback, or if we do it will not be all videos at once and they will be low quality with low FPS.
Computer vision has been commodotized thanks to limelight/photon vision and world class drive trains like swerve are now COTS. There is a massive discussion thread on CD about FRC getting easier over the years: Is FRC getting easier? Should something be done about it?
Many teams are bumping up against the skill ceiling of what’s possible in FRC and this could help to expand that scope.
Fundamentally we are limited by wireless spectrum and the radios we are using (802.11n). A new radio with support for more wireless bands/modulation rates should be able to do higher data rates, but FIRST would need to upgrade all the field APs as well.
See my post here: Is there any reason to not allow anything above 4 mbps? - #6 by Peter_Johnson
4 Likes
To add on, that limit isn’t really arbitrary. There was originally none, then it dropped to 7 and there were still events with major control issues. Dropping down to 4 solved most of the control issues at most events, which is why it stuck. It’s better than the old days where csas/ftas would come over to teams and tell them to turn off their cameras. That happens much less nowadays because of that limit.
7 Likes
In addition, designing an RF system gets exponentially harder if it needs to work the same, on the same hardware, legally, in different countries.
2 Likes
FIRST does a lot of things to make FRC resemble real-world engineering. A bandwidth limit (like a weight limit or a component restriction) is a very realistic real-world engineering constraint; you might encounter it with solutions as local as the rather limited bandwidth of Bluetooth, or as remote as the data rate to the Mars rovers via the Deep Space Network.
Arguably, designing solutions that work within such a limitation is a “better” engineering challenge than allowing a free-for-all with unlimited bandwidth. It forces one to consider alternate solutions, better algorithms, the tradeoffs of on-board vs. off-board processing, etc.
2 Likes
