[Dave Flowerday]

Originally Posted by Kevin Sevcik

The new DS's disable system works on a normally closed principle. Which means that your robot won't run at all unless you have a valid disable switch in place.

Kevin, I agree that the normally-open setup of the IFI system was a deficiency (though here was a feedback LED on the OI as I'm sure there will be on the new DS so you could verify it was disabled). However, the switch position is not the only problem. If the new DS can take up to 2 seconds to get the disable command to the robot, that is a problem. A lot of damage (to people or robots) can be done in 2 seconds. I realize this is a problem that they will have to solve before competition (no one will tolerate 2 seconds of lag), but the fact that the bug exists while teams are actively working with it on their robots means that the dangerous situation is already a reality.

On a Windows machine, the OS uniquely identifies each USB device and tags settings and functionality to follow it around based on its ID, as opposed to what port it's plugged into.

This is not always true - it is up to the device's driver how to treat it. There are many Windows devices that end up being identified by which port they are plugged into. In some cases, the USB devices have no unique serial number and therefore cannot be identified at all other than by which port they are plugged into.

For the DS we expect it to identify the joystick based on what port it's plugged into.

This is built-in functionality of the USB spec. A USB host will only talk to one device at a time. When a computer boots up, it goes through a process called enumeration, which it individually identifies each device one at a time on each port. It inherently knows which device is plugged into which port because of the way the system operates. If you plug in two identical USB devices to a hub at the exact same time, it doesn't matter. The hub indicates to the host that a new device was detected, the host instructs the hub to establish a connection to the new device (in this case the lower port number), and the host sets up the new device. This process is then repeated for the other new device on a different port on the hub.

Even my limited knowledge of USB driver programming informs me that pinning things to an exact physical port is pretty darn difficult.

For a USB driver, not hard at all. As previously indicated, it's required. If Linux is used on the DS, then it would be fairly straightforward to implement the necessary means to identify USB devices based on the port they're plugged into.

If it takes the controller 15 seconds for each port to identify the joysticks on boot-up, I don't think you want the process constantly occurring while you're trying to drive.

The USB bus generates the equivalent of an interrupt when a new device is connected. The host does not have poll. I have no idea why the DS would take 15 seconds to initialize a device, but I've used plenty of Linux boxes (including small, embedded ones with tiny, slow processors) and none of them took 15 seconds to identify a device.

The problems with old and uninitialized values being sent are slightly more worrisome, but aren't likely to be life-threatening if you're following commonsense operating rules. Also, if the 127 default startup and unplugged joystick values from the IFI OI made you feel safe enough to put yourself in harm's way, then you weren't operating under particularly safe rules in the first place.

I would not feel safe intentionally sticking my hand in an enabled robot based on the IFI 127 default value, but I can tell you that I've seen plenty of demos and such where a joystick was accidentally unplugged, and I'm really glad that the robot didn't take off full-reverse when that happened (by reading a 0 instead of 127). It's not hard to imagine a situation where a controller falls off a shelf, gets bumped full-forward or full-reverse, and then gets unplugged (leaving the robot moving that speed under the new DS). Then, in a quick instinct, you hit the disable button only to find out that it is experiencing a 2-second lag... well you get the picture.

Insinuating it was an afterthought is uncalled for.

There are demonstrated safety deficiencies in the system that FIRST shipped to beta teams. It is not uncalled for. Someone had to prioritize the things that got developed on the DS, and obviously whatever functionality it has right now was either prioritized over the safety features that it currently lacks such as safe values when a stick is unplugged or was overlooked. Either way I don't think questioning the safety decisions is uncalled for.

FIRST robots are just as dangerous as many machines found in a shop, which typically have mechanical lockout switches and all sorts of other safety implements. Yet, with our robots our safety will depend almost entirely on the firmware in the DS and robot controller. Sure, we have a breaker that we can turn off, but how do you do that if the robot has gone nuts and is spinning dangerously fast in a circle? Being critical of the safety of the new system is in everybody's best interest. This is no time to simply drink the kool-aid. You probably think I'm overreacting, and I honestly hope you're right. If, however, I saw potential flaws in the system and didn't do something to call attention to them and someone got hurt, I would feel awful.