Go to Post That little 18 amp-hour battery has a really hard life in a FIRST robot. - eugenebrooks [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 27 votes, 5.00 average. Display Modes
  #76   Spotlight this post!  
Unread 10-12-2013, 10:34
FrankJ's Avatar
FrankJ FrankJ is offline
Robot Mentor
FRC #2974 (WALT)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2009
Location: Marietta GA
Posts: 1,944
FrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond repute
Re: Battery powered raspberry pi

Another option. Get one of the laptops on First Choice. They would be by definition legal since they are KOP?
  #77   Spotlight this post!  
Unread 10-12-2013, 10:36
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
Originally Posted by FrankJ View Post
Another option. Get one of the laptops on First Choice. They would be by definition legal since they are KOP?
I was just in the middle of responding to something on the same point so I will quote this and that response below.

Quote:
Originally Posted by magnets View Post
I guess what I'm saying is that you need to try driver station vision processing before you dismiss it as slow. It's slower, but it's barely measurable, and if definitely won't impact your robot's responsiveness, speed, or accuracy. You won't notice the difference. In fact, I'd be willing to bet that the pi will actually be slower. Most of the lost time isn't in transmitting, it's in encoding.
I am confused by why you would encode on your Pi if the Pi is doing the machine vision. Are you suggesting turning the Raspberry Pi into something similar to a Slingbox?

I admit to building an OmniVision CMOS camera with a ARM CPU built into it as a camera with integrated machine vision and some ability to stream samples back to another device over UDP. However the whole point was to do the machine vision at the camera. Think of it like the Axis cameras but more customizable.

Quote:
Originally Posted by magnets View Post
The USB drivers for the pi are pretty sketchy, and even if you're using the axis cam, you'll need to play around with FFmpeg and compile it yourself for the pi in order to get any decent amount of response.
(This next response also address's FrankJ's post above.)

This is a valid concern. When Team 11 first approached this problem this sort of additional complication was why we put a netbook on the robot. Drove it back and forth over the bump in the field a few hundred times with an SSD in it. Used a full copy of Ubuntu to attach to our USB cameras running a unnecessarily high frame rate (cause we could...it was more proof of concept and acceptance at FIRST competition on the field than anything we really needed for operation so we removed it mid-season). So far Team 11 has done this directly to V4L via Python and Java and via OpenCV. When you have the whole package with a really high performance processor and no obligation to get crazy making things it sort of makes more sense to use the package. The most important limitation is the price. You had to stay under the $400 cap. Good thing that the computing industry is constantly pushing down the envelope by quantity to the point we could get dual cores at several GHz, the SSD and plenty of RAM for that price.

The bigger question is: is the cost of this Raspberry Pi with the case and battery *really* all that good a decision for the price? The Raspberry Pi is cheap alone, but we are adding a lot to the package and that may just make it barely worth while. Though perhaps that's the challenge someone accepts and then they ignore that concern which is their right.

Quote:
Originally Posted by magnets View Post
The pi isn't really that much faster than the cRIO, especially running the distro of linux included with it. vxWorks (the OS of the cRIO) is pretty darn optimized in terms of networking with the camera/DS, unlike the sketchy USB and TCP stuff going on with the pi.
This is a faulty comparison. The cRIO because of the way it is developed for FIRST can not really deploy it's full performance for this application unhindered. I respect that FIRST did as they required to meet their criteria but as a result the cRIO is not offering your team it's raw and untamed performance.

This is the equivalent argument people used to bring against mainframes. Sure your DEC Alpha might be 1GHz and my Tandem Cyclone mainframe (CPU cabinets) is a mere 33MHz per CPU (times 20 CPU). However that Alpha is not using a VME system with a single large base of assignable interrupts it's using hard assignments with priorities you can't change. The Alpha is running a huge OS with a single disk system that won't evolve to the challenge. The DEC Alpha is not a true parallel system: it can not be fully partitioned to be asynchronous (where as a coprocessor on a FIRST robot is). There are many cases where a true parallel system can much more efficiently assign resources to simultaneous task than a single core or even cores in an SMP design.

As a result a mere clock speed comparison (which is almost never a valid comparison to start with between architectures) is going to be flawed badly. A purpose built computer only needs to serve the intended purpose as best as possible. A general purpose computer will always do a lot of things and make compromises as it goes.

The cRIO as implemented by FIRST is not specifically configured to be the best machine vision system it can be. It is an adequate machine vision system for a lot of circumstances meaning it's application in this regard is more general. It is notable that it can do this function, but honestly, can someone show me a working Java code example with an Axis camera (there is a piece of code but it does not work and I've had 10 people try to make it work)?

Quote:
Originally Posted by EricH View Post
Under last year's rules, such a system would NOT be legal, or if it WERE legal, it would be impractical. Last year's R34 (should have) made that VERY clear: ALL electrical energy had to come from one of the two legal types of robot batteries, UNLESS the battery in question was integral to a COTS computing device, and only powering things connected directly to said computing device.
...

tl;dr: This ain't gonna be legal, or you're gonna be building and selling quite a few of them. And, as pointed out earlier, engineering only looks easy--get right down to it, and you'll have enough obstacles popping up to make you wonder why you ever got into this project.
As stated previously: I prefaced this concern earlier by contacting FIRST engineering directly.

I've contacted them in the past about making several things for FIRST: electronic motor controls, robot based oscilloscopes, the 2015 FRC control system. FIRST's requirement for a COTS device is that production is available to be adequate for all takers. There is no line to blur. You want to claim something is COTS you are then selling it to *anyone* with all that entails.

If the design is done properly, if the intent is to form a proper business venture, then FIRST based on the current rules and the conversation I had with them earlier this year would be hard pressed to reverse course. Does not mean they can't but so what if they do.

Regardless: FIRST has no business telling anyone what business they are in. For example: I own several business and am an Assistant VP in a huge corporation. FIRST can say whatever they like about me or anyone else. The only thing they can do is throw mud as long as I am a responsible business person. I doubt FIRST will ever stoop to that or it would be very ungracious professionalism.

I bid on the 2015 control system. FIRST said they were going to pass. I put that technology to use in 3 other fields using my existing ventures. In the process of that bid I exposed information about my design and key points of development. In doing that I gave FIRST access they could use to wander off with those ideas. I knew what I was doing and I, as a business person and inventor, managed that risk.

If someone is willing to accept the challenge of creating and maintaining a venture to makes this, approach it outside of the FIRST circles and whatever FIRST does becomes >irrelevant<. So what if they won't let you put whatever you made on the robot. The entire point of FIRST was to achieve goals larger than FIRST itself. So whoever does this has a venture that sells sealed battery enclosures for the Raspberry Pi. I am willing to bet there is a market for that regardless of FIRST and if not you diversify (welcome to small business put on your safety gear it's a bumpy ride).

Major points of FIRST are to inspire and to educate. If that creates:
1. A new business with potential employees.
2. A student who is interested in learning about manufacturing and all it entails.
3. An avenue to incubate ideas.

Then FIRST has achieved the goals it set forth.

Course Yash101 really has to ask if this huge challenge is something worthwhile to pursue.
Cause soon enough you will be dealing with: lawyers, the State, the Feds, insurance companies and real deadlines.
Do not underestimate the pressure or the complications: good businesses and people fail all the time.

The good news is that with a finite scope of the project outlined, examples elsewhere of similar attempts, this is something a student could aspire to do. Though I grant all those with concerns: mind the safety aspects and do not underestimate the technical challenges (I have built several charging systems for electric vehicles, electronics and military application there are many crucial subtle details that must be considered and all of them are irrelevant to the casual onlooker - it may not be all that interesting to the onlooker but engineers need to be concerned with it).

Last edited by techhelpbb : 10-12-2013 at 12:27.
  #78   Spotlight this post!  
Unread 10-12-2013, 20:03
efoote868 efoote868 is offline
foote stepped in
AKA: E. Foote
FRC #0868
Team Role: Mentor
 
Join Date: Mar 2006
Rookie Year: 2005
Location: Noblesville, IN
Posts: 1,421
efoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond reputeefoote868 has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
Originally Posted by techhelpbb View Post
I've contacted them in the past about making several things for FIRST: electronic motor controls, robot based oscilloscopes, the 2015 FRC control system. FIRST's requirement for a COTS device is that production is available to be adequate for all takers. There is no line to blur. You want to claim something is COTS you are then selling it to *anyone* with all that entails.
Added emphasis, as this is a point I'd like to address. One reason in particular that FIRST would be fine with having extra batteries integral to COTS components on the robot vs. teams fabricating their own devices with "integral batteries" is because there is already an element of safety to COTS devices.

A laptop or tablet manufacturer will have already designed out the risk to the lithium batteries in their device; they will have dropped and kicked and abused the devices to the point of failure many times over to ensure it is safe for the end user. While putting their device on a FIRST robot might not have been their intent, the forces involve should be pretty similar to the abuse the device will take in the real world.

The manufacturer is confident enough in their device that they're willing to take on liability when selling it.

Yash, you might be excited to take on the challenge of designing, prototyping, manufacturing and selling this device. You need to appreciate how dangerous lithium batteries are. Even if you pick a different chemistry, safety is still a very real concern for any electrical circuit. So much so, that you may even succeed in everything you do - build a working prototype, design it for manufacture-ability and all that, only to find that no one wants to take the risk in selling your device, so it never becomes COTS.

Just a heads up.
__________________

Be Healthy. Never Stop Learning. Say It Like It Is. Own It. Like our values? Flexware Innovation is hiring!. We're looking for Senior Automation, Software, and System Engineers. Check us out!
  #79   Spotlight this post!  
Unread 10-12-2013, 20:13
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Battery powered raspberry pi

Quote:
Originally Posted by efoote868 View Post
Added emphasis, as this is a point I'd like to address. One reason in particular that FIRST would be fine with having extra batteries integral to COTS components on the robot vs. teams fabricating their own devices with "integral batteries" is because there is already an element of safety to COTS devices.

A laptop or tablet manufacturer will have already designed out the risk to the lithium batteries in their device; they will have dropped and kicked and abused the devices to the point of failure many times over to ensure it is safe for the end user. While putting their device on a FIRST robot might not have been their intent, the forces involve should be pretty similar to the abuse the device will take in the real world.

The manufacturer is confident enough in their device that they're willing to take on liability when selling it.

Yash, you might be excited to take on the challenge of designing, prototyping, manufacturing and selling this device. You need to appreciate how dangerous lithium batteries are. Even if you pick a different chemistry, safety is still a very real concern for any electrical circuit. So much so, that you may even succeed in everything you do - build a working prototype, design it for manufacture-ability and all that, only to find that no one wants to take the risk in selling your device, so it never becomes COTS.

Just a heads up.
Yeah. Thanks. I was thinking about starting with NiCad/NiMh, because it is hard to overcharge them to the point of explosion. I can have an MCU charge the battery to 95% and then put a very small amperage into the cell, to top it off slowly! I think that it still would be better to use a supercapacitor, with a tie resistor to discharge it automatically! I would like to test safety by: running it in a nitro rc car at top speed and ramming into steel (Bye bye, expensive RC car ), and hitting it with a hammer with a force greater than any robot would receive! Also, I would like to short it out and see what will happen. Also, I wish to seal the case with some sort of rubber or teflon, etc. so no metal shards will get in. Also, there will be a fuse soldered onto the battery pack!

Basically, I want to torture the device with a greater torture than what could be received by the device under the worst case!

I just thought, how should the power be transmitted to the SoC? Should I have a USB port? A miniUSB for the chip, debugging and configuration (like output voltage, preset to 5V), and a USB A Female to power the Pi?

Last edited by yash101 : 10-12-2013 at 20:17.
  #80   Spotlight this post!  
Unread 11-12-2013, 03:16
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
Originally Posted by yash101 View Post
I would like to test safety by: running it in a nitro rc car at top speed and ramming into steel (Bye bye, expensive RC car ), and hitting it with a hammer with a force greater than any robot would receive! Also, I would like to short it out and see what will happen. Also, I wish to seal the case with some sort of rubber or teflon, etc. so no metal shards will get in. Also, there will be a fuse soldered onto the battery pack!
With appropriate safety and supervision:

Throw it down the stairs into a concrete wall.

Bake it in the oven (not a microwave) while on and charging to say 120 degrees to simulate a hot desert day. Freeze it in the freezer.

Operate it near an open flame.

Put your wireless near it, put your phone near it, put an AM/FM radio near it.

These sound really dumb but your can find a lot of problems like that:
RF emissions
Temperature sensitivity
Mechanical sensitivity
Production of hydrogen gas from charging
  #81   Spotlight this post!  
Unread 11-12-2013, 08:22
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Battery powered raspberry pi

Quote:
Originally Posted by techhelpbb View Post
With appropriate safety and supervision:

Throw it down the stairs into a concrete wall.

Bake it in the oven (not a microwave) while on and charging to say 120 degrees to simulate a hot desert day. Freeze it in the freezer.

Operate it near an open flame.

Put your wireless near it, put your phone near it, put an AM/FM radio near it.

These sound really dumb but your can find a lot of problems like that:
RF emissions
Temperature sensitivity
Mechanical sensitivity
Production of hydrogen gas from charging
Even better, I can just toss it outside on a regular sumer day. I left my iPod out for 30 minutes accidentally (during a robotics presentation only) and the solder on the inside nearly melted! I will check for hydrogen production, but I doubt it will produce any. Using a NiCad, as previously suggested, it should be not problem. However, let me do a little research on the material. I have 4 WiFi routers and an area just full of wireless communications devices. That could probably help see if RF is any problem. Mechanical sensitivity is going to be there. I am going to try to make it more durable than CIMs, which work for multiple years!
Oh and yeah, they aren't really dumb. They are really just another way of saying, "the fact" or how to do a true safety test!

I'm right now working off a Propeller chip (I know it is a dumb idea, but It's good for prototyping until I get a PIC). I was thinking of a 1000uF electrolytic cap, shorted with a 1Mohm resistor, to slowly discharge it after the power is disconnected. A step-up-down circuit will bring the voltage to 3v, by storing the 12v in a capacitor to make it only a quarter full. This will then go to the battery. This will all be controlled by the MCU to make sure nothing bad happens. There will be a transistor controlling the charge going to the battery. A reverse-protecting diode will be on the battery pack. That diode will make sure the power goes back into the 5v boost converter in one way. The MCU will do the boot-converting too! After I draw the block diagram, I'll post it on CD or my server!
  #82   Spotlight this post!  
Unread 11-12-2013, 15:07
apples000's Avatar
apples000 apples000 is offline
Registered User
no team
 
Join Date: Mar 2012
Rookie Year: 2012
Location: United States
Posts: 222
apples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant futureapples000 has a brilliant future
Re: Battery powered raspberry pi

Quote:
Originally Posted by yash101 View Post
Even better, I can just toss it outside on a regular sumer day. I left my iPod out for 30 minutes accidentally (during a robotics presentation only) and the solder on the inside nearly melted!
Wow, that must have been a hot day. The solder in your ipod melts at 400 degrees Fahrenheit.
  #83   Spotlight this post!  
Unread 11-12-2013, 15:31
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Battery powered raspberry pi

Quote:
Originally Posted by apples000 View Post
Wow, that must have been a hot day. The solder in your ipod melts at 400 degrees Fahrenheit.
It's nothing big! I live in the middle of the desert. Also, that is just in the summer! I just put it in the shade and it was good after 5 minutes, though hot to the touch! At least the magnets behind my iPod weren't demagnetized! Neodymium magnets demagnetize under high (read:low) temperatures!

Also, what about placing it charging inside a 500 watt subwoofer cranked up to full? I think that would be a good test, while being dangerous. However, it would get my neighbor's nerves!

Last edited by yash101 : 11-12-2013 at 21:00.
  #84   Spotlight this post!  
Unread 14-12-2013, 17:25
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Battery powered raspberry pi

Here's my design so far. I need to now create a pats list and CAD a schematic! Time for DipTrace! Check out the block diagram, and let me know if I am missing something!
  #85   Spotlight this post!  
Unread 15-12-2013, 16:40
magnets's Avatar
magnets magnets is offline
Registered User
no team
 
Join Date: Jun 2013
Rookie Year: 2012
Location: United States
Posts: 748
magnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond reputemagnets has a reputation beyond repute
Re: Battery powered raspberry pi

I think you forgot to attach your design.
  #86   Spotlight this post!  
Unread 15-12-2013, 23:21
yash101 yash101 is offline
Curiosity | I have too much of it!
AKA: null
no team
 
Join Date: Oct 2012
Rookie Year: 2012
Location: devnull
Posts: 1,191
yash101 is an unknown quantity at this point
Re: Battery powered raspberry pi

Quote:
Originally Posted by magnets View Post
I think you forgot to attach your design.
Sorry. I didn't notice that CD doesn't support TIFs! I uploaded it, but I get CD rejected it! Here's a new version (PDF)!
Attached Files
File Type: pdf 1654F7_02401.pdf (205.7 KB, 21 views)
  #87   Spotlight this post!  
Unread 16-12-2013, 09:36
Joe Johnson's Avatar Unsung FIRST Hero
Joe Johnson Joe Johnson is offline
Engineer at Medrobotics
AKA: Dr. Joe
FRC #0088 (TJ2)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1996
Location: Raynham, MA
Posts: 2,648
Joe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond reputeJoe Johnson has a reputation beyond repute
Re: Battery powered raspberry pi

This is KINDA related so I hope folks will not mind if I ask this here. If people think I am hijacking the thread, say so and I will start a new one.

Sensors on arms, fingers, .... are always a pain the in the eye. I love them but pots seem to always give me fits.

I have an idea for putting incremental encoders on the motors (quad input, 2 pulses per motor rev.). Using these incremental encoders, I can have something like an Arduino keep track of absolute position. But, that means we have to zero the count at some point. Okay fine. We do that in the pits when we are always calm, cool and collected (kidding). But we often have to cycle power on the field. Not only that but we often have to move the arm or finger or whatever while the robot is powered off. There goes the zero point for the CPU that is keeping track of the position.

Yes, we could have a switch on the mechanism that gives a zero point but do you want to do that at the beginning of autonomous? probably not.

So... ...I want to have a laptop or some such that has an integral battery that could stay alive during the power cycles on the robot and could also be a USB host for the Arduino(s) that are counting pulses and also act as a bridge from USB on the Arduino(s) to the some ethernet protocol (UDP I suppose?) to get data to the cRIO.

It seems to me that this would be legal (assuming the 2013 rules apply in 2014).

What does the Chief Delphi community think?

Joe J.
__________________
Joseph M. Johnson, Ph.D., P.E.
Mentor
Team #88, TJ2
  #88   Spotlight this post!  
Unread 16-12-2013, 10:37
FrankJ's Avatar
FrankJ FrankJ is offline
Robot Mentor
FRC #2974 (WALT)
Team Role: Mentor
 
Join Date: Feb 2011
Rookie Year: 2009
Location: Marietta GA
Posts: 1,944
FrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond reputeFrankJ has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
So... ...I want to have a laptop or some such that has an integral battery that could stay alive during the power cycles on the robot and could also be a USB host for the Arduino(s) that are counting pulses and also act as a bridge from USB on the Arduino(s) to the some ethernet protocol (UDP I suppose?) to get data to the cRIO.
I think you are getting more complicated than the original problem of make a good mount for your transducer. I would only go down that road for a set of really good reasons.
  #89   Spotlight this post!  
Unread 16-12-2013, 11:42
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
Originally Posted by Joe Johnson View Post
So... ...I want to have a laptop or some such that has an integral battery that could stay alive during the power cycles on the robot and could also be a USB host for the Arduino(s) that are counting pulses and also act as a bridge from USB on the Arduino(s) to the some ethernet protocol (UDP I suppose?) to get data to the cRIO.

It seems to me that this would be legal (assuming the 2013 rules apply in 2014).

What does the Chief Delphi community think?
COTS laptop on the robot was legal in 2013, if under $400.
USB on COTS laptop to power another device like a camera was legal in 2013 (if that device is interfaced only to the COTS laptop).

Personally I'd use the Parallax Propeller for this, it has USB and the cogs lend themselves to reading encoders nicely, that said using that or the Arduino as a custom circuit should have been legal in 2013.

Keep in mind you are going to add at least 1 pound of weight doing all this.
Perhaps you can manage this with an Android device?

Last edited by techhelpbb : 16-12-2013 at 11:44.
  #90   Spotlight this post!  
Unread 16-12-2013, 11:52
Joe Ross's Avatar Unsung FIRST Hero
Joe Ross Joe Ross is offline
Registered User
FRC #0330 (Beachbots)
Team Role: Engineer
 
Join Date: Jun 2001
Rookie Year: 1997
Location: Los Angeles, CA
Posts: 8,590
Joe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond reputeJoe Ross has a reputation beyond repute
Re: Battery powered raspberry pi

Quote:
Originally Posted by Joe Johnson View Post
I have an idea for putting incremental encoders on the motors (quad input, 2 pulses per motor rev.). Using these incremental encoders, I can have something like an Arduino keep track of absolute position. But, that means we have to zero the count at some point. Okay fine. We do that in the pits when we are always calm, cool and collected (kidding). But we often have to cycle power on the field. Not only that but we often have to move the arm or finger or whatever while the robot is powered off. There goes the zero point for the CPU that is keeping track of the position.
Why not use the flash memory in the cRIO periodically save the position? The preferences class in C++/Java would be great for this. You'd have to choose when to save the data carefully, to avoid hitting the flash memory 100,000 write cycles. It could be as simple as press this button then power off the cRIO, or as complicated as saving it each time it stops moving.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 16:11.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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