Quote:
Originally Posted by magnets
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.
|
I might be wrong (about which topic) but I am pretty sure that a few pages back in this very topic I related that I communicated with FIRST about bundling a Raspberry Pi with a battery as a COTS product entirely outside of FIRST. They can not stop you from doing that. It does bypass the approval process that FIRST would require for the product to be specifically FIRST approved. If you try to pass through the approval process you will get a delay while it's tested and you'll have to provide free product (actually they would really like you to provide all of the items for all of the teams for free...I doubt that is conducive to being sustainable).
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:
Originally Posted by yash101
I agree with the fact that driver-station vision processing is a great approach. However, there are still latencies. The comparison between onboard processing with the Pi and the DS would be totally dominated by the DS. However, if you were using something much more powerful, e.g. the oDroid, if the team is able to conquer doing it, that seems like a better option!
|
I disagree. If the bandwidth to the driver's station was in fact 100% reliable then it would dominate. The fact is there are multiple complications getting data to the driver's stations to analyze it. Bandwidth limits, potential wireless errors and other avenues for strange complications. Therefore there is ample handicap for the driver's station approach even with a lower performance system on the robot. Not to mention this makes the driver's station laptop even more a requirement for your team's robot so if something happens to that laptop your team might be setting up a crisis for a very expensive and potentially hard to get piece of equipment (I've seen teams get in deep trouble with powerful driver's station laptops).
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:
Originally Posted by yash101
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!
|
Using a PID like that is a bad idea. The surges alone will outrun your PID loop. You want to go over the voltage required for the Pi then step that down or linear regulate the extra voltage away as heat.