|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools |
Rating:
|
Display Modes |
|
#61
|
||||
|
||||
|
That would be nice! However, there is only 512 MB of RAM! It would be hard to fit the OS and the memory within the RAM, unless you get a special Pi with 3GB of RAM!
|
|
#62
|
||||
|
||||
|
Re: Battery powered raspberry pi
One way to power a PI would be from the USB port on the CRIO? Since the CRIO is on the buffered 24 VDC power supply that would protect it from brown outs that the 12 volts bus is subject to. I have not personally tried this so buyer beware.
|
|
#63
|
|||||
|
|||||
|
Re: Battery powered raspberry pi
The FRC-cRIO has no USB port.
|
|
#64
|
||||
|
||||
|
Re: Battery powered raspberry pi
Silly me. For some reason I thought there was one.
![]() |
|
#65
|
||||
|
||||
|
Re: Battery powered raspberry pi
You can buy a USB module for the cRIO, but the FRC FPGA won't recognize it.
|
|
#66
|
||||
|
||||
|
Re: Battery powered raspberry pi
For some reason I thought the 4 slot Crio had a USB port. Probably goes back to discussions about the Kinetic & old overused brain cells. By rule you couldn't use the USB module anyway.
|
|
#67
|
||||
|
||||
|
Re: Battery powered raspberry pi
I think I should design a small lithium battery pack of something like 180mAh to be COTS legal. Maybe have an MCU to automatically switch to battery and send a signal to the Pi to shut down before a timeout (hard shutdown).
What do ya guys think about some system to get legal in COTS, to allow a small battery? Also, if I were to do something like this, what should be the communication? Also, note that I am aiming not for the RPI, but for devices like the oDroid, with a higher consumption. I think you'd be better off doing driver station vision than using a Pi! So, I thought of a small LiPo Charger circuit, EXCEEDING safety standards, to charge the battery off the robot battery, or a computer mini-USB. That would go into a boost converter rated for 5V out, because a 1s battery means 3v7. Then, it powers an MCU, being the power manager, to tell the Pi to kill all processes and shut down. Then, the Pi, powered by a MOSFET will be disconnected by the MCU. Then the MCU will go into sleep/watchdog mode, waiting for the battery power to be regained, or the power switch to be turned off. I think that if I can make something like this in the Christmas Break and get it FRC legal, probably by 2016, not before 2015, it could be a game-changer for one of the teams who wants vision tracking! About powering the Pi/other SoC from the robot battery: There are the power pins on the header of the Pi. There is an FRC-legal boost-buck converter with a 5-volt output. Please let me know if you would like a picture of it on Wednesday. That should do the work, much greater than what it is required because I think it is rated for either 3 or 5 Amps continuous! However, I do not know if that provides very tightly regulated power since it is a buck-boost converter, so I would put something like a 15V, 100uF electrolytic capacitor in series with the Pi to eat up the voltage sparks that could kill the Pi! That should get you rocking and rolling with powering the Pi at competitions. Other than that, has anyone tried a supercapacitor (one meant to hold a large charge and not release it instantly) to power a part of the Pi like the CPU/RAM/other important thing? This is the type of capacitor used in RTCs so they don't forget the time. I think it is time for a modded Pi that has the ability to sleep, by turning off the processor and everything except the RAM. The RAM would be suspended to make sure it's contents stay where they are. Also, I think there may be some ways detect when the match is over to automatically shut down the Pi. I think that may be the easiest option! Last edited by yash101 : 09-12-2013 at 18:35. |
|
#68
|
||||
|
||||
|
Re: Battery powered raspberry pi
That's a neat idea. However, you might want to think about how much work you'll need to put in for the reward you'll get. Designing and selling a raspberry pi battery pack is a lot of work, especially if you don't know that it will be legal in the future.
Instead of going through all the trouble to compile the linux kernel with hard float math, designing the battery system, and writing software to communicate between the cRIO and the pi. Something that seems as simple as the communication between the two devices can be really, really difficult and full of hard to diagnose bugs and glitches. Look at team 118, the robonauts. At week three in their build season, they have a robot that can outscore 95% of teams final robots. Their robot didn't move at all in the Einstein rounds in 2012 because of a networking issue between their onboard processor and the cRIO. Their network buffer overflowed and vxWorks crashed. Most of the great cyclers this year (think 1114, 254...) didn't even have a camera, so you should look at vision systems from 2012. I'm not saying you should just copy somebody, but the expression "steal from the best and invent the rest" applies here. Many teams were quite successful with driver station image processing, either using the default tracking code and adapting it to run on the pc, or creating your own using openCV. 341's 2012 vision code is public, and was by far the best vision system that year in terms of simplicity, reliability, accuracy, and speed. Using a smartdashboard plugin works really well because you don't have to worry about sending data. Coming from a team who spent a ton of time working with vision stuff, I could program 3 of our competition robots with driver station vision processing in the amount of time it would take me to design, manufacture, and program the raspberry pi + COTS battery pack. Also, I'm not entirely sure how your battery pack will work. The rule says "Batteries integral to and part of a COTS computing device are also permitted (i.e. laptop batteries), provided they’re only used to power the COTS computing device." which seems to me that a laptop, or tablet with battery is ok, but your COTS battery is not a computing device, and I don't think that you can resell a raspberry pi legally. The rule implies that the COTS part must power itself, and only itself. So you couldn't take one computing device (a laptop with battery) and power another laptop with it. Each COTS device must power itself, and there just isn't a raspberry pi with battery device. By my interpretation of the 2013 rules, your COTS battery pack would be legal to power the MCU in the pack, and only that. No external devices can be powered. |
|
#69
|
||||
|
||||
|
Re: Battery powered raspberry pi
Quote:
Maybe I could start a petition to show FRC how many teams out of the ~5000 teams want this! I'm pretty sure that those teams doing powerful vision tracking would be the first ones to sign it! By the way, do you guys think that I should use boost-linear voltage conversion, or boost-buck conversion. By boost-buck, I really mean, just boost the voltage to 5V. the later option would be more efficient and wouldn't catch fire if you tried drawing more than an amp. However, there would be quite some noise in the system! However, the first option would get rid of the voltage spikes, but send all the extra voltage/current to heat. If you input 13v2 to a linear regulator for 5v, you would get (5/13.2)% Efficiency, with the rest of the energy being directly converted to heat! Last edited by yash101 : 09-12-2013 at 20:01. |
|
#70
|
||||
|
||||
|
Re: Battery powered raspberry pi
I think you should reread the my last post.
If you're looking to have an separate processor with camera capable of processing image data and sending it back to the cRIO, then look at the CMUcam 5. It costs $69, which is way cheaper than a pi and a webcam, and I guarantee that this will be cheaper. Also, it's a ton of work to make something like this work well, something beyond one person, or even one team could do. Just think, is it worth it to spend all the time, money, and resources of you and your team developing this solution when there are already solutions? Driver Station vision processing is proven to be as effective as onboard, and it's simpler, cheaper, and more reliable. You can't argue against any of these. When you say "it's not rocket science" it shows me that you haven't really spent much time with vision in the past. This stuff is tricky. One of the best and most technical teams in FIRST didn't move on Einstein because of a little glitch related to networking with a vision processing board, and some of the people who were involved in the development process were rocket scientists! You vision code needs to work early in build season so you have time to design your robot around it and test and tune. If you have detailed knowledge of the linux kernel, linux USB drivers, FFmpeg, OpenCV, networking, and a lot of programming experience, it is possible. Things that seem like straight forward and simple like installing the OpenCV libraries can be difficult and more time consuming than you expect. Also, how do you plan on building the power supply? On a printed circuit board? Coming up with a good layout is tough. Trust me. If you don't know what you're doing, and you don't have a good design with an effective ground plane to isolate interference, all your electronics will be plagued by random freezes, resets, and other unexpected behavior. If you're really set on using onboard vision, why not use a beaglebone? Or, wait until 2015, and use the dual core ARM processor in the roboRIO. |
|
#71
|
||||
|
||||
|
Re: Battery powered raspberry pi
Quote:
I am posting in this thread because this problem is not only in the Pi, but in many other SoCs that are suitable for this. Of course I don't have much experience. After all, I'm just a student. However, I am very curious and try to research and learn everything I come across. This is another reason why I come to CD! I'm just like a human octopus! ![]() I agree that without a plan, things will get out of hands quickly. Before I start anything, I brainstorm it and go through an engineering design process. Then, I draw a block diagram of what will happen, followed by a drawn diagram of the parts I will use and how they will be hooked up. From there, I will move to CAD and create a schematic. I first use something like Fritzing because that will help me breadboard things. I will fix errors that I find, then. Finally, I will CAD the thing in DipTrace, get the schematic down and then finally use DipTrace to generate a PCB layout. Finally, I make the PCB and then populate it with components. Then, I test it to make sure it works. I then start marketing it. I start a KickStarter, work on improving on it and raising popularity in it. Then, I will work on making it much more robust, by adding an aluminum case, over-rated heatsink and all sorts of other safety measures. Then, I will finally report the final product to FRC. Note: I have been calling it a product. It will be a product to be possible sold somewhere like AM or VexPro, but it will be non/little profit! I actually have looked at the CMUCam KickStarter and really liked it. However, it doesn't seem powerful enough to work well! I like to go with simplicity. I was thinking about a MOSFET-triggered, inductor-based step-up/down converter to slowly fill a capacitor to just 5v, +-.1v! I think that is in the working range of the Pi, and it should be a no-problemo, using a microcontroller to trigger the MOSFET. I wanted to use PID to do the voltage-holding! Last edited by yash101 : 09-12-2013 at 21:26. |
|
#72
|
||||
|
||||
|
Re: Battery powered raspberry pi
Quote:
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. 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. 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. |
|
#73
|
|||||
|
|||||
|
Re: Battery powered raspberry pi
Quote:
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. Now, there would be a potential loophole, if you happened to completely drain the battery pack before each match and charge it very quickly off of the robot main battery during autonomous--but that quickly goes south when you realize that the charging is going to take time, probably more time than the match. Let me make this even clearer: As few as 3 seasons ago, maybe 4, the COTS computing device battery exception did not even exist. It didn't exist until AFTER a team managed to get a computer onto their robot under then-current FRC rules that extremely limited such items. 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. |
|
#74
|
||||
|
||||
|
Re: Battery powered raspberry pi
I agree. I'll have to say that the DSP on the Pi sucks too! I boot from a harddisk and I am barely able to graze the available speed! However, as I mentioned, even though I use a Pi as my WebServer, I'd hate to use it for vision processing. The DS would beat it by many times with the FPS you can vs the Pi!
But, I really don't see too much latency in using a communication method like RS232/I2c/SPI/CAN/DIO/Parallel/UART (similar as RS232, for those who don't know about it)/etc. I have a good idea! let me have a linux laptop acting as a router, running in school, running on the greatest-used channel. That way, I might be able to simulate the network conditions in competition. Note, there are many APs in school, so tons of WIFI interference is available. The Linux computer should be running BackTrack-Linux, testing all the network parameters, like signal quality, etc. and recording it in a file. The Linux computer should also be running iftop, netstat and other utilities to measure the throughput etc. On the DS, the response times should be recorded to be analyzed. That would give a birds-eye view of what's going on! |
|
#75
|
||||
|
||||
|
Re: Battery powered raspberry pi
Quote:
It would have to be designed to be safe because now the market in question is going to exceed FIRST (liability). Production would have to be demonstrated to be adequate for not just FIRST but the general market. The Raspberry Pi would have to be bundled as part of the product and it would have to arrive at the team assembled. As a start you'd have to address with Raspberry Pi the use of their name. I am pretty sure I have all the schematics and PCB layout for that board so you could clone it but again I don't know the legality of that with regards to the Raspberry Pi license (ask a lawyer I am not a member of the bar). Quote:
Keep in mind your team does not control the field. If your team can't get your data to your team's driver's station and can not figure out why: you are out of luck. You can entirely simulate a vision system contained on the robot regardless of the presence of the field during development. Quote:
Last edited by techhelpbb : 10-12-2013 at 11:18. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|