Future FRC Technologies?

[sraque]

Stepper motors. The most common robot technology I can think of that we are not introducing to our students.

[marshall]

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.

[GeeTwo]

Originally Posted by marshall

I don't get it. I get that this is a system going out of control, but I don't get what this has to do with the first non-lithium post I have seen.

[Billfred]

Originally Posted by GeeTwo

I don't get it. I get that this is a system going out of control, but I don't get what this has to do with the first non-lithium post I have seen.

I believe it was an addition for emphasis of lithium batteries' dangers.

(And yeah, I wouldn't dare entertain a lithium battery that wasn't in an OEM hard case. Nor am I looking forward to the safety advisors' job the first couple years they're out there.)

[ratdude747]

Originally Posted by pilleya

There are two main types(most commonly used) of LiFePO4 cells 18650’s and A123’s

Laptop Batteries, cordless tool batteries(lithium ones), Tesla car’s etc.
Use 18650 cells.18650 cells look like big AA batteries.

The safety of 18650 cells is well documented, like all high capacity batteries they have the potential to be very dangerous. Most battery packs which use them, such as in laptops or cordless tools, have a lot of protection/safety measures built in to prevent problems. If FRC was to move towards LiFePO4 batteries, for safety reasons I would say that the some elements of the electrical system would have to be redesigned, to limit the potential for injury/error.

Not really, you make the controller part of the pack, just like with laptop packs and the like. Even add a push button charge indicator for extra functionality at a low marginal cost. The hardest part would be the current sense circuit, as we're talking pretty high peak currents compared to most packs. Not to say it's not doable (it almost certainly is), but it would take a corporate partnership for this to happen in FRC. Unless somebody already makes rated packs with a sufficiently robust casing, in which case, half the work is done.

[lynca]

A Backup Battery.
Supplies power to the cRio and Router as backup to the main battery. Less time lost in router or cRio reboot.

The VEX cortex has a backup 9V battery that behaves in a similar manner.

[Drakxii]

For more complex games, like stronghold, project the relevant game data on the driver station window. That way the drivers/coach don't need to rely on the audience screen, which may or may not be blocked by field elements.

A simple game, in the kit off software bundle, that allows a person to walk through the game field. Allowing teams to get a clearer understanding of the field elements before building them. Also if the move part could be animated and/or have it set up for VR, that would be great too.

[scottgoering]

Originally Posted by Drakxii

For more complex games, like stronghold, project the relevant game data on the driver station window. That way the drivers/coach don't need to rely on the audience screen, which may or may not be blocked by field elements.

FYI, FIRST did try something similar to this in 2014 Aerial Assist. They used a spare ref panel screen to display zones credited for possession. From here:

Each ALLIANCE STATION has one (1) flat panel display centrally mounted above the middle PLAYER STATION. The
display shows the ALLIANCE each ZONE where the ALLIANCES’ ROBOTS have been granted credit for
POSSESSION. Further, the panel highlights the unique ROBOT-ZONE pairs that are recognized as ASSISTS.

Not quite the game data in each DS window, but at least they tried

I don't think it was used very much.

[Christopher149]

Originally Posted by scottgoering

FYI, FIRST did try something similar to this in 2014 Aerial Assist. They used a spare ref panel screen to display zones credited for possession. From here:



Not quite the game data in each DS window, but at least they tried

I don't think it was used very much.

I find it ironic that at MSC, I found myself looking at the arena jumbo-tron for the score instead of that panel even though the panel was only a couple feet from my head.

[XaulZan11]

Originally Posted by AllenGregoryIV

We already have systems that attempt to calculate robot stats (OPR, etc). Once wifi is allowed in the stands TBA or another system could be expanded to allow people to submit robot stats. Those stats could be rated or vetted based on how accurate previous submissions were etc. I'm not expecting their to be volunteers in charge of this, I'm talking about crowd sourcing it from the teams that are already collecting the data anyway.

I do think we are overdue for a central database where teams can upload their data after the event (and could be used during the event). Similar to TBA but for data, I think it would be a huge help at pre-scouting events. I always find it a waste that teams spend hours collecting data at their event and rarely look at it again, while there are other teams spending hours watching videos of the same matches to prepare for future events.

[AdamHeard]

I've been reading this thread all weekend on Mobile and it's been killing me... On desktop now and can reply.

Working at the system level, I'm responsible for designing and implementing (often lithium based) battery systems for motion control applications.

Lithium ion as a generic name, and Lithium Iron Phosphate (LiFePo4) as a specific chemistry are two very different things. Lithium ion is to dog as LiFePO4 is to german shepherd.

Lithium ion is commonly used as the name for most 18650s and cell phone cells, which I believe are commonly Lithium Cobalt Oxide, Lithium Manganese Oxide or some combo of the two. These cells are optimized for energy density (not power density) and not safety. There is a relatively low temperature thermal runaway condition that can be caused by physical damage (as this allows the anode and cathode to directly short) or temperature increase.

Lithium Polymer batteries (very popular in RC industry, and make a great show on battlebots) are different in that they use a polymer electolyte instead of a lithium salt. They are capable of higher power density than the cobalt and Mn lithium ion, but are often less energy dense. These also are not optimized for safety, and have the same thermal runaway condition.

Both of the above are used far more commonly than LiFePO4 and are made safe by the system design. They are spec'd where overcurrent is not a concern, they are balanced during charging (and sometimes during use), often have external current monitoring to prevent over current, temperature monitoring, etc... All of this with the goal of preventing thermal runaway.

Now let's get to the good stuff!

LiFePO4 is a very safe chemistry as compared to above, and comes in cell and pouch style. Some 18650s are LiFePO4, and a 26650 size was popularized by A123 Systems... but they do come in all shapes and sizes. LiFePO4 are far safer (which mostly comes from about 1/3 the energy density of the above). They are optimized for power density and safety.

LiFePO4 are commonly penetration tested (nail, etc... inserted entirely through the cell and out the other side) without any flame event, and often with the cell remaining perfectly functional. There will be some capacity loss, but it will keep trucking. They can be overcharged and discharged to 0V and recovered without safety issue (do not try this with other chemistires...), just some capacity loss.

LiFePO4 is a great option for FRC batteries as they are commonly used in SLA replacement applications where you you do 2/3 as many SLA cells with LiFePO4 cells, and use the same equipment. This isn't what I would recommend for FRC, as I believe we should still have a balance unit but it would work.

Considering the SLA batteries we use are essentially 4-5Ah batteries (see spec and explanation of law), a LiFePO4 pack could be made that would safely run an FRC robot for 4-5 matches and have a retail price of $200-250. The battery would last for a great deal more cycles than the SLA batteries as they aren't affected by the deep discharg nearly as much. Our team goes through 12 SLA batteries per year, and would we switch to probably 3-4 LiFePO4 batteries and one new one every other year. Most teams could just run 2 and buy a new one every 3 years.

Lithium Titanate would also be another safe option if we stay in the stone ages long enough and price comes down...

[nuclearnerd]

Originally Posted by XaulZan11

I do think we are overdue for a central database where teams can upload their data after the event (and could be used during the event). Similar to TBA but for data, I think it would be a huge help at pre-scouting events. I always find it a waste that teams spend hours collecting data at their event and rarely look at it again, while there are other teams spending hours watching videos of the same matches to prepare for future events.

Agreed! But I think this is something the community can come up with no? It shouldn't be that hard to come up with a server and an API to allow teams to upload their stats. We can do it, we have the skills

I've always thought that it was a bit crazy how much redundant data entry gets done at competition. I love ideas like this where we can all benefit from working together. The harder problem is convincing teams to share when they might want to guard their data to maintain a competitive advantage. There's also the problem of someone intentionally or unintentionally uploading misleading stats. It would need some kind of account system where we can reward contributors, and moderate abusers. Not easy, but doable....

[ASD20]

Originally Posted by nuclearnerd

Agreed! But I think this is something the community can come up with no? It shouldn't be that hard to come up with a server and an API to allow teams to upload their stats. We can do it, we have the skills

I've always thought that it was a bit crazy how much redundant data entry gets done at competition. I love ideas like this where we can all benefit from working together. The harder problem is convincing teams to share when they might want to guard their data to maintain a competitive advantage. There's also the problem of someone intentionally or unintentionally uploading misleading stats. It would need some kind of account system where we can reward contributors, and moderate abusers. Not easy, but doable....

I think the hardest problem is convincing teams to all scout in a similar way. Right now, every team scouts differently and collects different data, but for a system like this to work and be accurate, you would need multiple people per event collecting the same data set. I think a lot of teams will not like the data that the system would collect and will end up doing their own thing instead.

As far as ensuring accuracy, the thing with a similar problem that comes to mind is Waze and their crowdsourced road condition reporting. They also have a relatively small (I presume) amount of reports for each event and need to make sure they are as accurate as possible. I don't know exactly what their system is, but I think it would be a good starting point for anyone who is interested in making this happen. FRC has the advantage of being able to also reference the FIRST match API for some things (Ex: If someone reports that each robot on an alliance makes 5 high goals in a match and the API reports 7 total, you know something is wrong).

[AllenGregoryIV]

Originally Posted by lynca

A Backup Battery.
Supplies power to the cRio and Router as backup to the main battery. Less time lost in router or cRio reboot.

The VEX cortex has a backup 9V battery that behaves in a similar manner.

I'm not sure what problem that would fix anymore. We could get rid of the brownout conditions if we had one, but most radio and roborio reboots are from physical disconnections and which aren't immediately solved by a backup battery.

I do think backup batteries are a good idea because you could then switch out batteries during demos without needing to reboot the radio/RoboRIO.

Originally Posted by ASD20

I think the hardest problem is convincing teams to all scout in a similar way. Right now, every team scouts differently and collects different data, but for a system like this to work and be accurate, you would need multiple people per event collecting the same data set. I think a lot of teams will not like the data that the system would collect and will end up doing their own thing instead.

As far as ensuring accuracy, the thing with a similar problem that comes to mind is Waze and their crowdsourced road condition reporting. They also have a relatively small (I presume) amount of reports for each event and need to make sure they are as accurate as possible. I don't know exactly what their system is, but I think it would be a good starting point for anyone who is interested in making this happen. FRC has the advantage of being able to also reference the FIRST match API for some things (Ex: If someone reports that each robot on an alliance makes 5 high goals in a match and the API reports 7 total, you know something is wrong).

This system doesn't have to completely remove redundancy, in fact it works better when more teams are scouting. What this would do would allow teams to see real stats from events they aren't attending, as well as the general public.

This system wouldn't be comprehensive, teams are free to track whatever stats like personally but many of them could be added to the this central database. Largely teams track things such as high goals made the same way or at least can easily produce that stat for every robot they scout. There are other similar stats that most people agree on each year and if there are some less tracked stats, the system could show how many people/teams have submitted for that stat and possibly have some way to rank if you should trust that stat or not.

[MasterMentor]

Originally Posted by AllenGregoryIV

Ability for the robots to access the live scoring data from the FMS.
Teams could build their own score overlays into their dashboards or future HUDs.

Robots could actually confirm that a scoring task was complete, very useful for auton.

Lots of other uses I can't think of right now.

While that would seem useful during the match, what would then constitute a replay? If the updated score/details didn't make it to your system within 10ms? 100ms? 1000ms? If the data wasn't updating on your DS because your DS was either AT or NEARLY AT maximum CPU utilization (and how would you prove that?!)? Would anyone then easily accept a backup DS from the FTA?

I do agree that having the data published to the DS in the same manner that the match timer is published to the DS would be considerably beneficial, but I'm not sure that it would be reasonable to *depend* on that data in-match. But, even unofficially, it could be incredibly useful to have that data in real-ish-time.

-George