Future FRC Technologies?

[AllenGregoryIV]

What technologies would you like to see implemented in FRC in the future?

A couple I would like to see,

1. Field view network cameras
A camera mounted on a pole above each driver station. The camera streams are available to each robot and each driver station. Each camera would be setup to view roughly half the field.

Overhead cameras are proven technologies in other events such as Robocup but doing the same for an FRC field would be very difficult. Driver station mounted cameras could be installed for every game without adding any complex overhead rigging.

The autonomous options would be very useful. We could also remove the need for teams to bring their own camera and pole setups like we had this year.

Dedicated cameras that are part of the field, would also allow FIRST to standardize a video replay system for use by the referees.

2. Faster wireless network connections
The eventual move to AC or other faster wireless standards should let us remove or increase the bandwidth cap.

[Bkeeneykid]

Advanced vision systems

A while back, I saw a team who was using a KickStarted LIDAR camera to do their vision. While I think there are some very powerful things you can do with just a camera, having a full 360 view, with depth sensing of the entire field would be an awesomely powerful resource.

More automated scoring

This is less for teams use, but to stop the "Ref, I'm SURE I went over those ramparts! I swear!". This ties into your field view idea, which could help, but frankly, as much as we all love our local refs, no one is perfect. This of course depends on the game,too. A fully auto scored game would be useful, refs just to catch fouls.

[pilleya]

Brushless motors

Having a few small, low power brushless motors and a certain brushless motor controller being legal could allow students to learn about different types of motors. They are also more efficient and have greater power to weight ratios over even the most advanced brushed motors.
Inexpensive Chinese Brushless Motors ( ICBM’s) are also widely available.

Battery technology

In the past decade(s) there have been significant advances in Lithium-Polymer battery technology. Some small battery packs now have 65C ratings. Lithium Ion batteries such as 18650 cells are used in a vast array of devices ( laptops, cordless tools, Tesla vehicles etc.)

Although there have been these advances in battery technology I firmly believe that at the moment those technologies are far too dangerous to be used for a replacement for the SLA robot battery currently in use. Even a small error, especially in a large battery pack( such as would be used in FRC) can be extremely dangerous and can lead to large fires and explosions. The SLA robot battery certainly has enough stored energy while remaining quite safe, and is something that does not need replacing.

[NWChen]

Modern batteries
Sealed lead-acid batteries are heavy, have poor energy density, and have a shorter lifespan than lithium batteries. For the high-amperage, high discharge rate application that FRC usually presents, I hope the standard SLAs can be phased out in favor of newer battery technologies.

pilleya has a good point about fire safety though - FRC's success is heavily reliant on its ability to keep participants safe, and until lithium batteries can become less dangerous their arrival is understandably far in the future.

Usable simulation tools
Gazebo/FRCSim's low-profile debut in 2015 was disappointing - I saw more threads on CD about installation issues than usage questions. Catalyst/similar games are useful for understanding the field, but don't effectively allow teams to consider the potential designs and strategies of different robots during alliance play. A low barrier-to-entry simulator which combines accessible 3D modeling and good interface design could increase the level of play for many (especially low-resource) teams.

[EricH]

Originally Posted by Bkeeneykid

More automated scoring

This is less for teams use, but to stop the "Ref, I'm SURE I went over those ramparts! I swear!". This ties into your field view idea, which could help, but frankly, as much as we all love our local refs, no one is perfect. This of course depends on the game,too. A fully auto scored game would be useful, refs just to catch fouls.

Just as a note, the first time this was tried was '06. A number of mistakes later, the automatic scoring was backed up by human counting, and a pause was inserted between auto and teleop to allow a live double-check. In 2010 and 2012, the scoring was much more reliable and didn't need the double-check (other than maybe referees' gut sense); 2016 BOULDER scoring was fully automated. I want to say that '08 had automatic robot scoring. Come to think of it, 2010 had an automatically-applied penalty!

Now, that being said, all of those games had an element that the referees still had to check--with the exception of 2016, the robots' position at the end of the match was it. 2016 added in the robots' motion through certain areas...

And, just to elaborate on some of the mistakes in '06, most of them weren't necessarily the sensors' fault, but the field design caused some problems. Balls jamming on the low goal's corral and working up towards the sensor--and onto the sensor--could easily confuse it (15 balls scored when only 10 could have?), and the high goal that year had a tendency to jam.

Things have certainly gotten better, with more linear counting systems and better feeds to them, but there's still a ways to go.

[pilleya]

Originally Posted by NWChen

Modern batteries

Sealed lead-acid batteries are heavy, have poor energy density, and have a shorter lifespan than lithium batteries. For the high-amperage, high discharge rate application that FRC usually presents, I hope the standard SLAs can be phased out in favor of newer battery technologies.

But here’s the thing, I really don’t see weight being much of an issue. Yes, they do have a shorter lifespan than lithium batteries, but they are also cheaper than Lithium batteries of comparable capacity.

The FRC battery is capable of high-amperage( much higher than the 120amp breaker allows), but do we really need it, as I see it the SLA can give out enough power to run the robot just fine. Higher discharge rate simply means more potential for danger.

Higher energy density means that batteries are capable of causing more damage and injury.

At one regional event I attended I saw two or three batteries swell up, because they had been shorted out by teams. The fact that the batteries swell when shorted and then pop, is great compared to Lithium-ion and Lipo batteries that just get hot and create a big fireball.

This is a competition for students, and students make mistakes, as do parents and mentors. What do we want the outcome of someone making a mistake with a battery to be, having the battery destroyed and need to purchase a new one. Or have the battery destroyed, and have it create a big flame/fire that can really badly injure people.

[Ben Wolsieffer]

Originally Posted by NWChen

Usable simulation tools
Gazebo/FRCSim's low-profile debut in 2015 was disappointing - I saw more threads on CD about installation issues than usage questions. Catalyst/similar games are useful for understanding the field, but don't effectively allow teams to consider the potential designs and strategies of different robots during alliance play. A low barrier-to-entry simulator which combines accessible 3D modeling and good interface design could increase the level of play for many (especially low-resource) teams.

This project appears to be trying to fill this role: http://bxd.autodesk.com/

[ASD20]

Originally Posted by AllenGregoryIV

2. Faster wireless network connections
The eventual move to AC or other faster wireless standards should let us remove or increase the bandwidth cap.

Sort of along with this, eventually lifting the ban on wifi. I understand that right now the technology is not there, so this change would not happen for a while, but when it is possible, it will make scoutung systems and other things much easier to implement. I am also curious about what creative new things teams would develop for competitions if they are able to use wifi.

[tjf]

Originally Posted by ASD20

Sort of along with this, eventually lifting the ban on wifi. I understand that right now the technology is not there, so this change would not happen for a while, but when it is possible, it will make scoutung systems and other things much easier to implement. I am also curious about what creative new things teams would develop for competitions if they are able to use wifi.

From what I can tell, it's just easier for FIRST to not allow it whatsoever. Only having to worry about Field Coordination for Wifi rather than Field Wifi & User Wifi can quickly run into Quality of Service dropping dramatically, something I'd rather now happen during Einstein F3.



Plus, you get teams be more inventive about scouting data transfer (audio / QR / Bluetooth / Network over USB / etc.) I think the learning process actually teaches more when writing scouting apps. Difficult challenges produce inventive solutions, kind-of like the competition itself.

A potential alternate-use would be to switch back to non-Wifi transceivers for Robot ==> DS comms, though you then get back to the issue of if you lose your driver-station transponder, you're out of luck...
Full Disclosure: I tried to write a scouting app and wanted to throw my desk out a window...

[bdaroz]

More to the point w/ the wireless discussion....

Lock the FRC wireless comms to the 5GHz, prohibiting any other uses, and let 2.4GHz be used by the teams for non-field use.

It's increasingly difficult to get connectivity in venues, especially if you need to use cellular, other than via WiFi hotspot (the old USB modems haven't been updated in a long time and don't match the current frequency bands of most providers)....

[tjf]

Perhaps the largest contribution I could see for FRC tech is to open-source & allow the Driver Station to run on ALL major operating systems, rather than just Windows.

In addition to not having to worry about Windows updates as much, it'd allow teams running Linux or macOS (for any number of reasons) to not use WINE / Bootcamp / Parallels Desktop. The fact that WPILib is open-source, as well as The Blue Alliance, many team's robot & website repos, and QDriverStation & FRC Drive, just to name a few, and yet the Driver Station remains a close-source and OS-exclusive piece of software seems almost counter-productive.

A Short, Collected List of Opensource & FRC
https://github.com/gluxon/DriverStation.js
https://github.com/the-blue-alliance/the-blue-alliance
https://github.com/Team254/cheesy-arena
https://github.com/WinT-3794/QDriverStation
https://github.com/AquaMorph/FRC-Drive

[jtrv]

Robots on the same alliance directly communicating with each other. I have explored the thought myself but it isn't currently feasible, as it requires core robot design principles to be pre-arranged by multiple teams, and that assumes they both make it to the same alliance in playoffs anyway.

[hectorcastillo]

Flotation Devices, Propellers, Waterproofing, Etc

You know what I'm taking about

[EricH]

Originally Posted by hectorcastillo

Flotation Devices, Propellers, Waterproofing, Etc

You know what I'm taking about

*WHAM!* OK, back to the regularly scheduled thread.

Propellers, Airfoils, etc.
*WHAM!* OK, back to the regularly scheduled thread.

I'll take a wireless communication system that doesn't take nearly a minute to boot and connect to the driver's station.

Brushless motors would be nice, I think, but the biggest problem is that in many FRC applications, stall is a very present issue. And many brushless motors hate stalling, at least in the power range that FRC would likely use. Tough challenge.


Something I'd really like to see isn't a technology item at all, but fits with automated scoring (and instant replay, which I see as being a few years out even if used): Field-element indicators. What I mean by that is something like that nice black line above the low goals this year: Something built into the field that can be used as a height/distance/size reference. It's really nice to be able to tell if a robot is too tall when it tries to do a chinup on the truss, for an older example. Could have used something like that for height checks this year. If they're there, they're great. If not... it's a little harder to make the calls. That could work in the teams' favor, or not.

[PAR_WIG1350]

Originally Posted by jtrv

Robots on the same alliance directly communicating with each other. I have explored the thought myself but it isn't currently feasible, as it requires core robot design principles to be pre-arranged by multiple teams, and that assumes they both make it to the same alliance in playoffs anyway.

This would actually be a good one to try to tackle, but perhaps not to the extent that you are hoping for. Currently, the programming for FRC is largely done by implementing the predefined abstract functions/methods/VIs(?). The same main code runs on every robot, more or less, and only the implementations of these functions vary from team to team. If there were a handful of such abstract functions that teams could use to provide the field with a standard set of parameters, combined with some additional (non-abstract) functions that allow the robots to query these parameters as reported by their alliance partners, basic information sharing would become possible. Additionally, since it would just be more of the same type of programming that teams are already used to, the added burden to the teams would be reduced compared to more complex cooperative schemes.

For example, If robots were to report when they lacked/desired more game pieces, a game-piece-harvesting robot could hold onto its collected game pieces while periodically polling how interested its alliance partners were in receiving them. The other alliance partners would independently write their own code for when to activate this signal based on their own strategies. While other game-piece-harvesters would likely never signal a need for game pieces, an exceptionally rapid scorer might always indicate a need for more. Other teams might tie this signal to a sensor in the robot or control it manually from the driver's station. Regardless of what the method of controlling the signal is, the response of the harvester would be the same. Perhaps the harvesting robot has an automatic turret that auto-aims towards the scoring side of the field, and launches game pieces towards the scoring robots without human interference, allowing the harvester's driver to continue to concentrate on harvesting.

It would work best if the game was designed to encourage the use of such a system, but it could definitely be done.