Quote:
Originally Posted by marcan
I'm not at all concerned with the interfacing PIC uC. The power usage of this is probably going to be very small compared with everything else. My main power hogs are external devices (over which I have little control, outside of disabling a few LEDs to avoid their power draw). However, the good news is that the worst-case power draw is not supposed to occur during normal operation, as the software should be able to configure the devices. Specifically, I want to be able to run a PS2 controller, and a Wii controller (I'm testing out different control schemes. I wonder how practical the Wii controller will be for manipulating a mechanism on the robot). With the Wii controller goes a Bluetooth module of course. Mostly everything is designed to run off of low power, but there are peaks in power usage during initialization mostly (the Wii controller blinks the LEDs which would be disabled later on via software, and the Bluetooth module uses more power during discovery). However, since the peak (init worst-case) power is well under 100mA, and the running power should be significantly under that, I think it should be doable. Everything is going to be powered off a 3V-ish buck converter (adjusted for efficiency).
|
Not to become the rules police here, but if this is for a FIRST competition, they'd nix the control because of the Bluetooth radio.
Quote:
Originally Posted by marcan
Pretty much the same here - I seriously doubt full resolution is going to be very important, since humans are very good at mentally calibrating such things out. The USB-Chicklet needs to work reliably and accurately (as if the USB joysticks were regular ones), but for our one-off I'm sure we can work out any little kinks in software. Here's an idea: if your current draw varies, you can tie extra inputs on the OI to GND+0.5 and +5V, and use them to do runtime scaling of the inputs on the RC to compensate for any differences.
|
Yes, I thought of that, and I suppose if you are pulling the +5V Aux power line down significantly, then it could be of some help. The flip side is that if the load was inconsistent, the asynchronous sampling of the analog inputs could cause you to introduce additional error rather than correct for it.
Again, the input sample rate is ~38Hz.
Quote:
Originally Posted by marcan
Crazy idea: wonder how much power the Wii controller's rumble uses? Probably too much, but I'll still give it a go for kicks. If anything, we could have some fun out of competition making the rumble activate when the accelerometers on the robot measure acceleration over a certain threshold.
|
At that point, you might be better off with another self powered, home brew device that watches the RC->OI data stream, extracts what it needs, and gives the driver the approriate feedback via a seperate alerting device, be it visual, rumble, or a tazer jolt. As long as the wiring doesn't tie into the same device that is wired to the joystick port, it should be permitted.