Originally Posted by PAR_WIG1350 (Post 1595309)

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.

Originally Posted by tjf (Post 1595295)

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

Originally Posted by EricH (Post 1595308)

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.

Originally Posted by PAR_WIG1350 (Post 1595309)

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.

Originally Posted by jtrv (Post 1595371)

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 :rolleyes: ).

Originally Posted by MichaelBick (Post 1595361)

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.

Originally Posted by Andrew Schreiber (Post 1595376)

In light flywheel applications.

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

Originally Posted by IndySam (Post 1595386)

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.

Originally Posted by GeeTwo (Post 1595390)

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.

Originally Posted by R.C. (Post 1595402)

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!