Future FRC Technologies?

[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.

[Abhishek R]

Heads-Up Display (HUD) Driver Stations

Something we always joked about making one day on 624, but the reasoning is entirely all too real. We would make the effort of lighting our robot with addressable LEDs so drivers don't have to look down at the computer to understand the state of the robot - they could stay focused on what's going on in the field. A HUD would give a lot more information than what can be shown in 32 LEDs and in a much visually clearer way as well.

Besides, eventually when these things get fancy enough - who doesn't want to feel like Tony Stark in front of a Jarvis UI?

[phargo#1018]

From an electrical engineer perspective, I find FIRST somewhat limiting. This is a chance to remedy the situation.

Perhaps consider allowing or facilitating access to devices such as FPGAs or PLDs. This could provide the opportunity to bring VHDL or Verilog designs into the robot design process.

As for brushless motors, they would be a great addition to these systems. They will increase, perhaps significantly, the wiring requirements on the robots. Additionally, care must be taken to manage the new failure modes; the motor drive commutates the machine, and not the brushes!

[Kevin Ainsworth]

Originally Posted by Abhishek R

Heads-Up Display (HUD) Driver Stations

Something we always joked about making one day on 624, but the reasoning is entirely all too real. We would make the effort of lighting our robot with addressable LEDs so drivers don't have to look down at the computer to understand the state of the robot - they could stay focused on what's going on in the field. A HUD would give a lot more information than what can be shown in 32 LEDs and in a much visually clearer way as well.

Besides, eventually when these things get fancy enough - who doesn't want to feel like Tony Stark in front of a Jarvis UI?

Here's the heads up display we used last year.
https://www.chiefdelphi.com/forums/s...d.php?t=136401

[AllenGregoryIV]

Originally Posted by Kevin Ainsworth

Here's the heads up display we used last year.
https://www.chiefdelphi.com/forums/s...d.php?t=136401

Hom many lumens was the projector that you all ended up using?

[MichaelBick]

Originally Posted by EricH

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.

I believe the current issues with hobby grade BLDC motors are mainly in the motor controllers. Sensored BLDC motors perform identically to brushed motors of the same power. However it is still hard to find affordable, reliable, BLDC motor controllers for sensored motors. Regardless, sensorless BLDC motors would likely be perfectly fine in flywheel-type applications.

[Andrew Schreiber]

Originally Posted by MichaelBick

I believe the current issues with hobby grade BLDC motors are mainly in the motor controllers. Sensored BLDC motors perform identically to brushed motors of the same power. However it is still hard to find affordable, reliable, BLDC motor controllers for sensored motors. Regardless, sensorless BLDC motors would likely be perfectly fine in flywheel-type applications.

In light flywheel applications.

I also believe CTRE was demoing a sensored BLDC controller at CMP.

[marshall]

Originally Posted by Andrew Schreiber

In light flywheel applications.

I also believe CTRE was demoing a sensored BLDC controller at CMP.

Yeah, they had one of their magnetic encoders connected up to a cheap brushless DC motor. It was quite cool.

[IndySam]

New, lets go back to the good old days. Backup batteries for the radio to help prevent problems with brownouts. Say connected and there's less need for quick radio reboot.