![]() |
Re: Battery powered raspberry pi
Quote:
Quote:
Quote:
Quote:
Currently, it seems as though here are some good choices, for the end product. PIC32 PIC PicAxe AVR SX [strikethrough]BASIC Stamp[/strikethrough] Quote:
Quote:
Quote:
[quote]For example an R/C time constant will make your timers temperature sensitive and will drift. Fine for something not timing sensitive but not so good if you need the timing of something predictable. [quote] I won't be using RC because it is hard to get very accurate values quickly. I am going to use an MCP3204, with a Sigma-Delta setup because it offers a very high refresh rate, faster than the Propeller can handle! Quote:
Quote:
Quote:
Quote:
Quote:
|
Re: Battery powered raspberry pi
Quote:
Look up the Microchip and Atmel product selectors on their websites it lists all the current production models and you can filter that list to find the ones that fit what you want. Quote:
Quote:
Quote:
PIC and PICAXE are both 8bit Microchip PICs. One has software in it already. Atmel AVR and the AVR MEGA are 8bit microcontrollers. Atmel XMEGA offer 16bit. Atmel AVR U3 offer 32bit (think PIC32 competitor space). The Parallax Semiconductor (previously Ubicom) chips are 8bit but fast. I have plenty of old SX chips I don't use because anything that needs that sort of RISC speed I probably move too much data to use those chips. Quote:
If you want to design PCB you may as well start learning how to connect parts because you can not avoid it. It's true that putting some things in the chips can reduce board complexity and the number of layers. However there are many examples of where putting something like an ADC in a chip produces a not so great example of an ADC because you can't alter the ADC to deal with system issues. I have 2 LPKF PCB mills. I make 2 layer boards all the time. There are many examples where I am assured that I need 4 layers and even in the RF range it works as long as I respect design practice and shield. PCB designing is a big job and requires a fair degree of knowledge. Do not fear it just learn how to do it because if you make a career out of electronics you'll be doing it again in the future. Quote:
The Propeller development boards come with the USB to serial adapters. You'll be in a situation where you don't have that. ISP is basically serial but usually it's not done these days with a serial port. There are plenty of cheap Chinese knockoffs of the PIC and AVR ISP programmers that work great. Quote:
Quote:
Now for a better question - what are you doing with that data? Quote:
It is an illusion that analog is dead >entirely<. An analog circuit is not subject to illusion of synchronized timing to a clock. True digital has valuable contributions it can make but truly an array of programmable transistor interconnects is an analog construct it does not require a clock even if it can harness it. In fact there was a company that used to make analog programmable circuits. I often see students trying to bang all problems with the same hammer. Anyone telling you as a student in high school you can't handle analog electronics is being dishonest. I was fixing tube televisions by 7th grade. In the context of your comments previously by the time I was in high school I was programming in assembler on 5 platforms and at least 3 of those professionally for parts of projects (at least one of those was a multimillion dollar job). So whatever reason I could handle that having graduated from high school in 1994 it shouldn't have become harder. Quote:
Quote:
Quote:
If that's the case you can't actually read all the inputs at the same time. You have to switch the mux. Quote:
Another good part about knowing your external ADC and it being SPI/I2C is you can pivot that knowledge to another MCU. So let's say you decide the Propeller is a way over the top for a production product. So you leave your existing ADC circuit and put it on the other MCU. That was a big factor in my choice in my helping to propose a 2015 control system. I wanted to know that peripherals were flexible. You could connect them to ARM, Atmel and PIC and connect those all together and the knowledge would transplant (mostly). Building blocks like LEGO instead of a limited COTS product. |
Re: Battery powered raspberry pi
Quote:
The lower voltage won't directly help me. It will help me in the voltage regulator etcetera. I like the multi-core environment much more, the reason why I want to use a Propeller for the host controller. I will dedicate a core to the settings, a core to continuously fetch the ADC and store it's value. There will be a separate core for each regulator, making sure that the current spikes don't cause sudden voltage ups and downs. This is the reason why I will use a semi-large capacitor on the output. I like using an MCU because the frontend will allow me to change settings like the output voltage. If I can calculate how much the voltage will be increased by each switch, the frontend can be used to set exact voltage, for example, 4.9v instead of 5v. Or, if you are wierd and want something like 12v coming from a USB port (Why would anyone want that?!?!), that could be set up! MCUs are just lovely because you can customize them completely and do what you want! I think that you will have problems in interrupt-based coding if you are used to multi-core, vice-versa. It's based on what the programmer has experience with. I didn't know that a PICAxe was a PIC with a bootloader! That's quite interesting, and probably why it is the "PIC"Axe! I program my Propeller in C already. However, for this project, I most-likely will switch to Assembler because of the brisker operation! Also, I know that MCUs aren't the best thing to use. FPGAs will still beat them. However, FPGAs will lack behind building the gates yourself and creating a circuit that does NO processing! MCUs open up a world of simplicity, however, If I program an MCU wrong, I can change the code. However, redesigning a PCB can be a much more expensive process. Compare and contrast this to a 3D printer. These make it possible for anyone to build prototypes without shelling thousands of bucks to a mold. In the other hands, using an injection molding system would mean a higher quality. Just think of an MCU as a 3D printer and an IMS as using transistors to build an autonomous system. Sorry about that. I typically call a Mux by a Multiplexer. You, being the guru at PAsm, probably know what can be done. With 20MIPS, an MCP3204 could be outrun, but I would have to be as good of a programmer as you, which won't happen in all of a sudden. You, being the guru, how would you code that? It seems quite complicated to run an entire set lines of code to initialize the chip, download the data and store the data in the form of a variable. Then, the same core will decide whether to switch or stay closed. Should I do it in a different method? I don't want the chip to double-switch and damage the electronics behind the regulator. I want this to be a measure twice (read:once) switch once, making sure no fatal errors exist. For PCB design, I want to start out with CAD and slowly learn tips and tricks to improve the layout. I'm pretty sure that the CAD software should work on making sure the CAD software will optimize the layout. What PCB layout software do you suggest? I could use Eagle, DipTrace Freeware, Fritzing, or Autodesk Autocad Electrical (My student account gives me access to this. However, it is only non-profit!) The data from the MCP3204 will be so that the Propeller can react to the changes in the stored voltage. Hey, DO you think that it would be wise to have a high-resistance trace between the terminals of the capacitor so that it will self-discharge quickly after the power goes out? That would be a safety measure, though the voltages in the cap bank would be small Just a random (and stupid) idea: Would it be possible to make a transformer on the PCB? The reason why I categorized the PIC32 differently is because they have quite a high max DMIPS rating, and they seem like a different architecture to me. Oh yes, the Chinese stuff! :) I love some of the Chinese stuff because a few products have a high quality and art dirt cheap! What about if I build an ICSP? They aren't too hard to build and I would get some soldering practice, and may even learn how to solder SMT! Would it be better for me to fabricate the PCB myself or to have it fabricated? :DI feel like I almost killed my Pi by writing this post on it:D |
Re: Battery powered raspberry pi
Phew! We've covered a lot of ground in that post.
How about a new tangent? Anybody used a Rpi and the 5Mpixel camera to do anything useful on a FIRST robot? I am thinking FIRST target ranging, but perhaps "find the big red/blue ball" would be useful as well* If so, do tell. Joe J. *it has been a few years since FIRST has had a big ball as a game piece. I suppose it is about time for a game with a big ball - my money is on that or footballs this year |
Re: Battery powered raspberry pi
Though I don't know any team that has done RPi processing, I'll have to say, the RPi is unsuitable for a high speed robot lie in FRC. It's hard to get the info you need with the lag you get. However, it is much faster than cRIO processing and you may get 2-3FPS!
As with color tracking, if you wrote code like the CMUCam5, he RPi would be the killer machine, capable of many times the framerate. Why don't you try the CMUCam? It may be what you're looking for ;) |
Re: Battery powered raspberry pi
Quote:
Quote:
Quote:
You can always practice interrupts on the PC you used to program the Parallax Propeller. Quote:
The FPGA has the advantage of the gates being close together. Therefore even if you use the highest speed CMOS/TTL individual logic you can get the FPGA has the gates closer together. You have more flexibility with ICs instead of the FPGA for example you can get ECL instead of TTL where you want it. The scientific method and experience will tell you the best choice for the criteria of any solution at a point in time (which impacts what technology is available since you don't make your own semiconductors). Quote:
Start off with PCBs you draw with a Sharpie and etch yourself. There's a kit at RadioShack, ask for it, they usually have it in the back. Quote:
You make compromises all the time the key to expertise is to recognize them. Quote:
Quote:
You optimize a routine to fetch the data using one or more cogs if you need to (hint > the hub switch is sequential so you can read the same input from cog 1 as you can from cog4 < exploit that to reduce the timing and impact of the hub switch timing). From within the fetching cog(s) find the min/max/average and store the current. Use another cog(s) to grab the min/max/average and current reading from the hub shared memory (remember within a cog is faster than in the hub shared memory). You probably want to use a running average to reduce noise so you probably want a way to start/stop/restart that average based on flags stored in the hub shared memory. Quote:
Quote:
http://www.altium.com/en/first-robotics-competition It is powerful professional software designed to do this job. Quote:
Otherwise you are trying to make a PCB with a characteristic that is otherwise undesirable. Quote:
Quote:
So maybe a simple problem can run in one instruction at 4 clock cycles at 25MHz on a CISC CPU. That same problem can run at 10 instructions at 1 clock cycle each at 50MHz on a RISC CPU. Think it over. Here, this is worth lots of my typing: http://eecs.wsu.edu/~aofallon/ee234/...reOverview.pdf Quote:
Quote:
2. Then with iron on transparency film you can get from eBay or Mouser using a laser printer or photocopier. 3. Then send Gerbers and NC drill files out to a board shop. 4. Then send assembly drawings to an assembly shop. You can also solder mask yourself but then you need to get more involved. You can etch and Liquid Tin a board with hobby tools easily. Please be aware the etchant is an acid and should be treated with respect. Quote:
Quote:
Now....for something directly on topic: How many teams need/want a COTS enclosure with a battery powered computing device in it and which one? |
Re: Battery powered raspberry pi
Quote:
Ah, out of respect for your incredibly long trail of informative posts, I am very reticent to try to bring this up, but it is apparent that you are intimately familiar with the classic 8 & 16 bit PIC's, but have not explored the 32bit based products very deeply. Start here for some interesting new products released over the last few years http://www.microchip.com/pagehandler/en-us/family/32bit . Also, there is data about that shows that Microchip products are leaders in memory efficiency in 8, 16 and 32 word sizes. Plus, stuff like this make for a new world http://www.microchip.com/pagehandler...makes-sen.html I'm trying to figure out how I can plop it (and the associated sensor suite) on a robot. On another front, I am amused at the argument resurfacing between CISC and RISC, as the technology sways back and forth between CISC (logic quicker than memory access) and RISC (memory close enough to feed short logic paths). A decades old battle; reality settles in the middle. And nearly irrelevant, given modern compiler capabilities. TJ |
Re: Battery powered raspberry pi
Quote:
The Microchip PIC32 M4K MIPS RISC instruction set is a Harvard architecture (see page 3 of the link from Microchip below). It also has interrupts. I have some sitting on my workbench to my right. http://www.microchip.com/stellent/gr...c/en542879.pdf As far as CISC/RISC the answer is whatever actually gets the job done as far as I am concerned. The same is true of interrupts as far as I am concerned. The rules of thumb (acceptability) here are often a question of popularity rather than science. Now in fairness - I've yet to find a use for the PIC32 in the projects I have in manufacturing. That does not mean I won't it's just been trumped by customer requirements, size constraints, cost concerns, and knowledge transfer concerns as several other chips I have laying about often are. It has plenty to offer just at the moment it offers more to me than to people I might sell it to (my requirements are always a different matter). So do I know about it yes. Am I a volume customer of the product no. |
Re: Battery powered raspberry pi
This probably isn't the "right" way or the best but it was cheap and worked well... I used a 12v - usb car phone charger and a female car charger port thingy... Worked like a charm and only cost a few bucks...
|
Re: Battery powered raspberry pi
Quote:
Back on track, a 12v USB plug will be a lovely option because they are meant to run off a voltage this high from the robot battery. They can also handle quite a good amperage, and you'll get them real cheap! |
Re: Battery powered raspberry pi
Quote:
If an engineer says that something isn't the "right" way, he means that it's not the way you're supposed to do it, but it's a way that works--and may become the way you're supposed to do it, eventually. (A lot of R&D starts when someone finds a way that isn't the right way.) But, that engineer could also mean that it's the WRONG way. In that case, you might want to listen, particularly if he says straight out that it's the wrong way. |
Re: Battery powered raspberry pi
So anyways,
So we have been powering our pi directly from the PD board's 5V out. It seems to be powering, though I think the SD is corrupt because it is always hard-reset. |
Re: Battery powered raspberry pi
Quote:
This will force file commits immediately - but it will negatively impact performance. |
Re: Battery powered raspberry pi
Quote:
It's a nitwit idea. Nitwit ideas are for emergencies. The rest of the time you go by the Book, which is mostly a collection of nitwit ideas that worked.From "The Mote in God's Eye" by Larry Niven and Jerry Pournelle |
Re: Battery powered raspberry pi
Quote:
You need a way to do an orderly shutdown. Perhaps send a message from the CRio when you transition out of teleop? |
Re: Battery powered raspberry pi
Quote:
I had a wierd idea. Do you guys know about those USB cell chargers? What if we use it on the bot? Wouldn't it be a COTS part? Otherwise, I thought of a fairly simple idea: A Large capacitor powers the Pi. That is charged from the robot battery and goes in only one direction because of a protection diode. There won't be a very high voltage (maybe maximum able to give a tingling sensation), so this could power the Pi. Also, it should discharge in no time, down to 0v7, beyond the threshold to electrocute even a foolish person. Here's a schematic |
Re: Battery powered raspberry pi
Quote:
The more important question is how large a production run does one need on a "Pi/Arduio/whatever + shield(s) + battery + enclosure" to qualify as COTS? Tim |
Re: Battery powered raspberry pi
Quote:
I am sure there's a market out there for a ready-made enclosure with battery and loaded with platform of choice beyond FIRST. It's getting more and more unlikely that anyone can prove they are at production volume for this season. You'd have to: open or have a business (it can be done in <24 hours), engineer the product, test the product, put the product up for sale with adequate evidence it's advertised to the general public (it might take 4-6 weeks to get into a monthly periodical so that's out) and finally have sales. Seems pretty unlikely. How much volume the initial run has to be is probably less relevant to success (where as it would matter to a FIRST approved product) than whether or not the business could meet delivery demands. People might wait weeks for a product like they did for the original batch of Raspberry Pi under the right circumstances. However waiting weeks pretty much ends any chances of working out during the 2014 season. With 2015 right around the corner - a good question is will FIRST continue with the COTS rule and allow auxiliary computing devices once the RoboRio is the new standard? Will FIRST decide that the RoboRio eliminates the need? Personally I think the RoboRio does not eliminate the need for this rule but that's just my opinion. |
Re: Battery powered raspberry pi
Quote:
|
Re: Battery powered raspberry pi
Quote:
Targeting FIRST (in the sense I am stating it and from my perspective) for a product means making the product particularly appealing for FIRST and attempting to limit your production to only what FIRST might need. It also likely carries with it using FIRST resources like the name and/or affiliated websites to advertise. The COTS rules in FIRST are really limited in scope to electronics. It's not that say a swerve is not COTS in the general sense but you don't need that rule to use a swerve module at all. You do need that rule for electronic items. So if you going to make an enclosure, with a battery, a charger and some other computing device in it and use it under the COTS rule it would be asking for trouble if: you ever refer to it as the maker like it is specifically for FIRST, ever mislead people that it's FIRST approved by using say the logo, only make production runs based on FIRST usage, make any assurance that it is allowed in FIRST or only do support for FIRST teams. Sure a team can make a custom circuit and share that circuit with another team. However it's not COTS unless it's really a product anyone (potentially everyone) can buy and it's sort of splitting hairs if it's entirely improbable to find a legit use for it outside of FIRST. However a custom circuit doesn't open the door to the extra battery like a COTS computing device does. Others may interpret this rule differently. However in my perspective as a business person if I am really targeting FIRST I really ought to get FIRST's approval. In the course of all conversations I had with FIRST about potentially making something like this as COTS I made it quite clear that if I did that myself it would be for sale with no mention of FIRST. If someone from FIRST uses it - that's their choice and not the result of my marketing. Any action I took that would effect FIRST would be no different than any action I would take for any other customer and especially while dancing this line I wouldn't give the product away for free to any team unless I am going to give it to all the teams like via the KOP. Effectively I wouldn't solicit public review from just FIRST relations or participate in such reviews publicly because that's unusual for general products. Could someone get away with operating on a different understanding of this rule: I am sure they could. I wonder though if they really understand the liability they are creating for themselves. |
Re: Battery powered raspberry pi
I do think it is time for a definition of COTS from FIRST. I'll get my guys to toss it in to Q&A shortly.
We are in a day & age of 3-D printers and plug & play H/W system development (Arduino et al). Will volume matter? Can the 2CAN from Cross The Road be done for less than $220? Easily, probably at a profitable price and that's why they are out of stock. What really gets my goat about the CAN thing is that the bloody processor buried down in the FRC cRIO (I & II) has multiple CAN interfaces, but we can't get to them. The next generation controller gets really interesting, with the controller cores buried directly in the FPGA part. I don't suppose they'll let us program those gates, either. Just a little rant :) TJ |
Re: Battery powered raspberry pi
Quote:
Quote:
|
Re: Battery powered raspberry pi
Quote:
That is truely one thing that FRC will need to clarify to fix all these loose ending. Until then, before actually putting the RPi on the bot, take out the SD card, run WinDiskImager and create an image of the card. That will save your life in case of a failure! Just prop the card back into the computer and write that image to the card, which you know works! For code, just create a web server on the driver station. Have a BASH script download all the code every time the RPi boots, and recompile it to make sure it is current, or compare the downloaded code to the old code to see if the downloaded code is newer, same or older! I think a simple Hash generator and checker should do the job. Also, remember that a lot of us will not be using the RPi,but something with many times the power. The RPi is only good for regular DIY hacking and development, not for performance. Also, I don't think it has OpenCL support :(. However, I may be outdated with that because I haven't used my Pi in a while! |
Re: Battery powered raspberry pi
Quote:
|
Re: Battery powered raspberry pi
Quote:
Think about it: the D battery is COTS. You don't fill it and if it's alkaline you don't have to charge it out of the box. So since the FIRST rules (as pointed out by Alan while I posted above) only let COTS computing devices with a manufacturer provided battery on the robot (as an integral part) on the field you have less choices. The idea earlier about the external removable battery so it's not on the robot during the match is a good thing to ask about. Capacitors skate this. However FIRST has been quite specific and I think pretty cool about even suggesting that someone outside of FIRST can make a COTS device with the integrated battery and use it on the official field. This makes it possible to fix this and bypass the approval process that could be ripe with other issues. So really the question is: is there really enough interest in FIRST and elsewhere to fix this mobile robot issue? If there is then the issues are strictly normal for any business or start-up. Course I really do think it won't be ready for this season. So if someone wants to tackle this problem - even if FIRST bans COTS computing devices next year - it would interesting. The point is to inspire a business in the general sense regardless of whether FIRST buys from it. |
Re: Battery powered raspberry pi
On the topic of goats ...
The Freescale part does indeed have CAN capabilities, and a certain CEO also really really wanted the CAN capabilities to be exposed in the industrial version of the product. But release deadlines don't always allow things like that to happen. For industry, CAN is also available through FPGA IP and a module, but this would have cut into other FPGA features. It was discussed and the group decision was to achieve CAN via serial or enet bridge. It certainly isn't ideal, and this is far improved in the new controller. The FPGA of roboRIO is reprogrammable. I'd personally love to see well-mentored teams play with it in the offseason. Good ideas from this could be incorporated in the official image. At the moment, we don't have a good technical ability to combine the closed and open portions of the IP into the same FPGA. Safety is the top priority, so it is expected to remain closed for FRC robots until we are able to do both. Greg McKaskle |
| All times are GMT -5. The time now is 03:31. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi