Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Rules/Strategy (http://www.chiefdelphi.com/forums/forumdisplay.php?f=6)
-   -   Rules Change I Would Like to See - Batteries (http://www.chiefdelphi.com/forums/showthread.php?t=149183)

ASD20 28-06-2016 14:10

Re: Rules Change I Would Like to See - Batteries
 
Quote:

Originally Posted by techhelpbb (Post 1594707)
So it's possible to make a bundled Raspberry Pi based device with a battery and sell it as a unit COTS. You must sell it to the general public essentially engineered with safety in mind. So the battery boards for the Raspberry Pi do not really cover this because they are not bundled with the system or even enclosed.

If a supplier is thinking of doing this, please do not make this. 3 times the price for a cable and a sticker.

techhelpbb 28-06-2016 14:50

Re: Rules Change I Would Like to See - Batteries
 
Quote:

Originally Posted by ASD20 (Post 1594722)
If a supplier is thinking of doing this, please do not make this. 3 times the price for a cable and a sticker.

Acrylic in laser cutter.
Glue.
Proper design.

I believe this could be done as a simple business but I don't want to start a business with returns this low myself. Might be willing to help someone else start it. There are a lot of good Linux systems that one could make cases with batteries for and provide simple assembly before delivery to the customer. Such as the ODroid XU4 and NVidia Tegras.

See the ODroid XU4 CloudShell as an example:
http://www.hardkernel.com/main/produ...=G143599699669

asid61 28-06-2016 22:30

Re: Rules Change I Would Like to See - Batteries
 
Quote:

Originally Posted by marshall (Post 1594669)
They are a problem though because they are currently illegal based on the rules. And why aren't they a concern? I've seen them go boom the same way I've seen LiPos go boom.

I've seen them go pop, but the long sustained fires that Lipos get (in my experience) seem more dangerous to my eye, especially because coin cell devices seem to be in more protected spaces for the energy they release. Feel free to disagree; both have their dangers.

Nothing other than the USB spec but you can dodge the spec. USB C is rated for 5 amps continuous and I'm not sure about surge but something tells me it could handle it. What's wrong with pulling 10 amps from another power source though? Is there something inherently dangerous about 10 amps? Doesn't the existing battery allow me to pull 10 amps?

The existing battery is protected via strict wire gauge and connection requirements, so although it can put out 10 amps, those amps are going through known sources all the way to the motor (apart from the odd current sense resistor). I wouldn't trust the average FRC team to make a giant power bank of USB connectors to power some weirdo 10 amp LED cannon. :P If we were to go this route, we would need strict regulations on the circuits they can attach to, making it harder on inspectors. Especially for a team like 900 that's constantly pushing the envelope, these new regulations might make it harder for you to use your preferred computing device.

Again, the safety concerns come from something going boom or something moving when it shouldn't be. Or maybe you are worried about someone being shocked? Either way, all of these can happen and have happened with the existing battery.

Not too worried about getting shocked by the 5v. :P

There is no inherent risk that is not already present with existing batteries and as I've already pointed out, these cheap battery packs are WAYYY more common than FRC batteries and many people seem to be using them everyday without issue to charge their cell phones.

There's definitely an inherent risk in handing people unregulated or loosely regulated power. I can't think of the wording they would use to ensure that the packs are used safely.

While safety might be #1, making it easier on teams to do cool stuff should be #2 or maybe #3. Enabling teams to run co-processors without worry of brownouts and similar makes it easier on the teams to do cool stuff.

Very fair. Is it possible to use a buck-boost voltage converter off the VRM? At what point does the VRM shut down/brownout?

[sarcasm]Yes, because partnering with another company to deliver parts is just that simple and that has never produced supply problems for FRC teams in the past...[/sarcasm] It also does allow weird loopholes and dangers... the part could become obsolete or it could have a manufacturing defect (*cough* white exploding tanks *cough*). Just because you think a company is reputable doesn't mean they are impervious to turning out a malfunctioning product.

I trust Samsung more than Alibaba. I make it a point not to buy batteries off Ebay, even though I'm extremely cheap.

Inspection is a challenge and I'm very cognizant of that. So, instead of training the inspectors on a particular part, train them to look at the control system and power pathways for the motors to ensure they are not being interfered with from a USB power source... I'm not saying it will be as simple as asking the team to point out any onboard power sources other than the big robot battery but you could and then verify they aren't plugged into any motors or motor controllers.

There are more things to power than just motors, is what I'm worried about. And inspectors would have a lot more on their plate form possible loopholes IMO.

You guys need to get real about this though. If you actually want to see this rule changed then suggesting that FIRST partner with another supplier for it and make rules about requiring specific part numbers just makes it more difficult, not easier. It puts the burden on the FRC folks to track down parts, get them donated, include them in the kit, write specific rules about them, etc. That's a lot of work for some already overworked people.

That's true, but I feel like that's the cost of doing it right. Or, they could just require a certain model of battery pack that is legal. That would be easier and let those teams that really want it use it.

An alternative, as I have suggested, is to change the existing rule to fall in line with the example that is already allowed under the batteries integral to COTS computing devices. No one is checking those specific devices or batteries but they are typically checked to make sure they aren't powering any moving assemblies on the robot.

That's fair. I also think that's an oversight, but not a major one due to the nature of the devices people are using now.

Also none of you addressed the existing loop holes that I already pointed out including a flashlight that could be considered a COTS computing device and using super capacitors, which I'm more worried about other teams trying to use than I am a cheap LiPo pack (I'm not actually worried, I encourage it, go use them because they are legal under the existing rules!). It is possible to make all of these items secure and safe though.

I believe super capacitors would be unable to do anything major without some serious workarounds, and that the presence of one in a power line would be noticed and questioned by an inspector. But, it hasn't happened yet, and I don't think it will happen soon due to the prohibitive cost and low utility/cost ratio. The flashlight isn't hurting anyone IMO, and the battery for it is safely tucked away.

And with that I'm done with this thread. I could argue with you guys all day about this. I've offered up a solution that makes sense and should make it easy. Stop arguing and actually think about the problem for a while. What I've said isn't crazy talk and is a good way to solve this.

Contrary to popular belief, I do think about stuff sometimes. I've thought about the problem and stated my case. I'm a little hurt that you don't consider my opinions valid. :\ I realize you have a lot more experience than I have or maybe even hope to have, but I still think that there are a lot of safety/inspection concerns associated with adding on another battery that are being skirted over.

See bolded text above.

snekiam 28-06-2016 23:03

Re: Rules Change I Would Like to See - Batteries
 
Quote:

Originally Posted by techhelpbb (Post 1594707)
So it's possible to make a bundled Raspberry Pi based device with a battery and sell it as a unit COTS.

What about this? Does that not qualify as both COTS and having a battery? I know its not in stock, but I don't see why it would be illegal.

techhelpbb 29-06-2016 07:44

Re: Rules Change I Would Like to See - Batteries
 
Quote:

Originally Posted by snekiam (Post 1594821)
What about this? Does that not qualify as both COTS and having a battery? I know its not in stock, but I don't see why it would be illegal.

Nope because again no enclosure and not delivered assembled together. The whole idea is the laptop/phone maker took steps to deal with puncture. The SparkFun Pi-Top laptop Marshall linked earlier may have the same issue, but because it looks like a laptop the inspectors might not catch it.

Basically FIRST wants to know that a company is backing up the safety of the device with their own liability using that power source. Using an assembly like you linked leaves the FRC team risk of liability if their package is inadequate. It is dubiously legal FIRST can argue that a laptop/phone maker intended their device for FRC use but they figure at least, as a package, a professional was involved with design.

Also supercapacitors are able to be used as part of a COTS device but as others have pointed out: the presence of power does not mean field safety is overridden. So the COTS device can not power robot motors directly. Therefore no USB rocket launchers from said COTS device even though you can buy said toy COTS. Technically I suspect USB powered fans would be denied as well, but internal cooling fans to the COTS device are okay. I have no idea how FIRST would react to a USB connected laptop cooler, that would be worth asking in the official Q&A. Point being: you should not be moving robot parts directly with the COTS device (my laptop cooler rarely tries to spin around and kill me...rarely ;)).

Quote:

Originally Posted by GreyingJay (Post 1594564)
Having a separate battery isn't without its own concerns. Assuming this became legal, you just know there will end up being a team somewhere, sometime that will be kicking themselves for losing a key match because they forgot to charge the battery pack powering their vision processing system.

We've had the on board laptop and a Kangaroo die before like this. However we've also had a whole robot get unplugged because the Anderson connectors were not all the way together. It's much easier to insert process to fix this issue than to insert process to fix unusual brownouts caused on a field you usually don't have access to with other robots that you don't have to test with.

Actually, I'd also like to see FIRST extend a power source for the radio. Beyond all the 3d party COTS devices we loose radio power with devastating consequences most often. Worse the power to the radio is not something FRC teams are really allowed to regulate or adjust themselves. So if the co-processor issue is annoying the radio power issues is a magnitude worse because right now we can't change anything as an FRC team to address it except check the wires, replace hardware or find the power draw (which may be from being stalled by a pushing match).

David Lame 01-07-2016 15:37

Re: Rules Change I Would Like to See - Batteries
 
Thanks to everyone who posted suggestions.

I think the real takeaway from this and related discussions is that as time goes by, coprocessors that require more and more power will become more and more common. If FIRST wants teams to be able to use these things, they'll probably have to have some sort of dedicated power solution for computing/vision/sensing devices, and will have to be sure that they can somehow make sure those dedicated power solutions aren't powering motors or other actuators, and otherwise won't kill anyone or start any fires.

For the meantime, I have a couple of different solutions in the works that I don't think break any rules.


All times are GMT -5. The time now is 06:45.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi