Digital to OI Analog

[Dave K.]

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.

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.

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.

[marcan]

Originally Posted by Dave K.

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.

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

R66:

The radio modems provided in the 2007 Kit Of Parts are the only permitted method for
communicating with the ROBOTS during the competition. Radio modems from previous
FIRST competitions can not be used. The radio modem must be connected directly to the
Robot Controller using one of the DB-9 cables provided in the 2007 Kit Of Parts. No other
form of wireless communications can be used to communicate to, from or within the ROBOT
(e.g. no Bluetooth devices are permitted on the ROBOT).

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

Originally Posted by Dave K.

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.

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

Originally Posted by Dave K.

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.

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.

[Dave Flowerday]

Originally Posted by marcan

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)

I think you'll get burned by R11:

<R11> For the purposes of determining compliance with the weight and volume limitations specified in Rule <R07>, these items are NOT considered part of the ROBOT and are NOT included in the weight and volume assessment of the ROBOT:
...
* The OPERATOR CONSOLE.
...
However, for all other purposes the items listed above are considered part of the ROBOT and must comply with all other applicable rules and equirements. In particular, these items are subject to the shipping deadlines specified in Section 4.5.1.1 and must ship in the crate with the rest of the ROBOT.

Emphasis mine. Since the operator console is "part of the robot" when interpreting R66, you cannot use wireless communications to or from it (in my interpretation).

[Dave K.]

Originally Posted by marcan

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.

At competition...

<R63>, <R66>, and Section 3.14.3, make it reasonably clear that other than the 900MHz radios, no wireless communication is permitted. The one exception is <R109>, but that doesn't apply here.

This may be helpful: http://forums.usfirst.org/showthread...ight=bluetooth