Future FRC Technologies?

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

[ASD20]

Originally Posted by PAR_WIG1350

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.

I'm personally partial towards the coaches shouting at each other "Pass me the ball" method.

[ASD20]

Originally Posted by tjf

yet the Driver Station remains a close-source and OS-exclusive piece of software seems almost counter-productive.

The Driver Station is closed-source for a reason. FIRST wants to have complete control over robot communications for safety reasons. I believe OS-exclusive is just to make things easier for FIRST. According to the internet, it appears that around 90% of consumer desktops/laptops run Windows, so it is not surprising that FIRST doesn't find it worthwhile to support other OS's.

[Aeglos]

More Battery Stuff
Having backup batteries, super caps, or at the very least sturdy boost/ buck regulators on the RIO and whatever wireless router we're going to use after the FCC nonsense would go a long way towards allowing more complex/ power- hungry mechanisms to be used, and would likely significantly decrease comm/ response issues.

3D Printing/ CNC/ Laser Cutter/ Waterjet Services
Though my team is very lucky to have these provided to us by our local sponsors, and even has some of these capabilities in our tool shop, i know that many other teams may not have these privileges. This could help to level the playing field a slight bit, if FIRST or some partner organizations could provide these services at a relatively low cost to teams. I think this isn't really unreasonable, especially with the ever- decreasing costs of machining and making complex custom parts. Some convenience would be lost, of course, but it would still give many newer or less privileged teams the opportunity to make awesome custom systems and components.

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

[jtrv]

Originally Posted by PAR_WIG1350

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.

One thing that immediately comes to mind is 148's 2015 robot. That might be the greatest potential for teamwork that was never fully utilized.

In regards to code, I'm not sure. Wireless communications are very strictly locked down while on the field to prevent field signal interference, which I understand, but I think is quite harmful to the growth of control systems within FRC, and I can only dream of the day teams are more free to implement their own wireless communication systems (provided it doesn't flop as hard as the Kinect idea ).

[asid61]

Originally Posted by jtrv

I can only dream of the day teams are more free to implement their own wireless communication systems (provided it doesn't flop as hard as the Kinect idea ).

You call this a flop!?
https://www.youtube.com/watch?v=ZaOiaC0I8pY
They saw the opportunity, and they took it!

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

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

[dirtbikerxz]

Originally Posted by R.C.

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!

I don't think I can ever get myself to not change out a battery between matches