Originally Posted by marcan (Post 567391)

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).

Originally Posted by marcan (Post 567391)

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.

Originally Posted by marcan (Post 567391)

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.

Originally Posted by Dave K. (Post 568220)

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.

Originally Posted by Dave K. (Post 568220)

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.

Originally Posted by Dave K. (Post 568220)

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.

Originally Posted by marcan (Post 572049)

Notice that the Bluetooth communications stay within the Operator Console, and everything is channeled through the IFI radio. Thus, no other method other than the IFI radios is used to communicate "to or from the robot" (and certainly nothing within)

Originally Posted by marcan (Post 572049)

I believe radios (other than the IFI ones) are only prohibited on the robot, not on the OI.

R66:

Notice that the Bluetooth communications stay within the Operator Console, and everything is channeled through the IFI radio. Thus, no other method other than the IFI radios is used to communicate "to or from the robot" (and certainly nothing within)

Either way though, we'll have alternative control methods available, both because of the possibility of having the Wiimote denied, and to see which is more practical. If nothing else, we can still use the Wiimote out of the field :)


Of course, it would work best when the load is constant or varies with a very low frequency (which will likely be the case of many control systems).


True. Not that I think it would really be that useful in competition, it's just something that would be easy to do just for kicks, given what we already have. I've written a custom dashboard that, besides doing what the original does, also shows stuff like the camera vision system data, and a couple other things, so adding it onto that would be fairly trivial.