Future FRC Technologies?

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

[GeeTwo]

Originally Posted by 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.

Sam, perhaps I missed it, but you have the first post I noticed that mentioned a separate controls battery that was not specifically lithium based. I'm all in favor of a more dependable power source for control circuits, but I'm not sure that Lithium is ready to be that source. +1, at least.

[dirtbikerxz]

I would really like all robot communication to be on 5ghz. So that 2.4 ghz hotspots will be viable for teams that need to get online. And also, better bandwidth for the bots themselves.

I agree with more automated scoring. While I noticed this in a few matches, I remember one particular match, I know for a fact I fully crossed the ramparts three times (from neutral to opponents court yard), but the ref only counted it as once, and we lost the match due to that.

I realize a game like this year makes automated scoring of crosses hard. For example if we did some sort of sensor that detects movement, than a boulder rolling over might trigger it etc. I just wish there was a better solution.

[Deetman]

Originally Posted by dirtbikerxz

I would really like all robot communication to be on 5ghz. So that 2.4 ghz hotspots will be viable for teams that need to get online. And also, better bandwidth for the bots themselves.

I've seen this in a few places already and want to correct... When on the field all robot communication is already over the 5GHz Wifi spectrum. There is an associated 2.4GHz network for the FTA, but that is not mission critical and is subject to the extreme congestion of the 2.4GHz spectrum at many venues.

[marshall]

In the future, all robots will be programmed in Javascript.

I am kidding and I really just wanted to link to Gary Bernhardt's talk because I find him hysterical and this thread reminded me of it.

[R.C.]

Originally Posted by GeeTwo

Sam, perhaps I missed it, but you have the first post I noticed that mentioned a separate controls battery that was not specifically lithium based. I'm all in favor of a more dependable power source for control circuits, but I'm not sure that Lithium is ready to be that source. +1, at least.

IMO lithium polymer wouldn't be a good choice for FRC. BUT Lithium phosphate or lifep04 is what FRC should switch to. Teams would have to buy fewer batteries and the same battery could last 2-4 matches!