New Info on 2009 control system, maybe

[ParkerF]

Originally Posted by Mike Soukup

Ridiculous.

We used the 1 byte display on the IFI controller for quick pot calibration in the pits and at our practice field and for feedback about our autonomous programs. Now our drivers will have to hook up a laptop instead? Bad move FIRST.

Now I am completely oblivious to the function of any and all electronics with the new DS, but I know there are several output pins on the side. Could these or even one of the USB ports be used to set up a second LCD screen for custom input?

[Kevin Sevcik]

Originally Posted by francistexas

Now I am completely oblivious to the function of any and all electronics with the new DS, but I know there are several output pins on the side. Could these or even one of the USB ports be used to set up a second LCD screen for custom input?

Doubtful. You have 8 outputs, and the data is transmitted at 50Hz at best, so bit-banging the outputs isn't likely to work well. The USB ports are thus far only for joysticks and a USB key for firmware upgrades. The Linux OS might recognize anything something else plugged into them, but you won't have any way to interact with it from the cRIO. The only real option is a dashboard laptop/netbook/PDA/whatever. I recall them saying the specification of the dashboard packets were open or would be. If so, you could really use almost anything with a LAN port on it to display things. I mean, most dashboard programs are going to be pretty lightweight. Ebay is currently listing 1,800 <$100 laptops with 1GHz or better processor and at least 512MB of RAM. I know it's not going to be as easy as just dumping a variable or two to the user byte, but an actual dashboard laptop is likely to be a lot more useful.

[AdamHeard]

I agree that the difference in the physical implementation of the disable switch is better, but what happens after that I still won't trust anytime soon.

I *know* when I hit the disable switch on an IFI system, the robot is stopping.

I don't know that about this new system, especially after some of the things that have been happening. I don't care one bit about what it is designed to do, or what should happen when this switch is hit. I care what actually does happen, and if what happens is a 2 second delay after disabling, that can be a very big deal.

Yes, unsafe situations can and should be avoided and relying on the disable isn't the best idea. But in my years of FIRST I know of several times when code was downloaded or a trim was mis-set and the robot just started going/moving a joint and someone had to lunge for the switch and it had to work. Or sometimes even tuning a PID loop on a joint where someone made a programming error and it took off the wrong way; that two seconds could mean great damage tot he robot, or less likely, to a person.

I'm not really criticizing the new system, I'm just hoping people won't be so trusting of it until it has proven it's reliability; I don't think that is one bit uncalled for.

[Kevin Sevcik]

I'd just like to point out that as far as I can tell from what's been said here and on the beta forums, there's no information one way or another on whether this communications lag actually affects the function of the disable switch. That question's been asked on the beta forum, but hasn't been answered yet.

Second, I have to disagree that the joysticks holding the last sample is a safety deficiency. In most situations, this implementation is equivalent to the IFI default value system. If the USB device is controlling something like a PID positioned joint, the holding value implementation is arguably safer than suddenly jumping to any default value. As pointed out, the default value implementation is safer for most drive systems. So I think the new control system's functionality is just as safe or unsafe as IFI's. It's just different. If we want to argue them into changing it, I think it'd make a lot more sense to ask for the functionality that we actually need. As opposed to the functionality that we've grown used to dealing with. What we need is for the API to throw an error and/or return an invalid value when we try to address a joystick or axis that doesn't exist. Returning NaN would be perfect for this, as any operation on NaN returns NaN or false. I'm half certain that the PWM functions will already shutdown an output if they're commanded to output NaN. There's probably a few situations where this wouldn't completely safe things or would adversely affect things long after the joystick is replaced... But overall I think this should be preferred over switch from one less than satisfactory solution to another.

[willson.thomas]

I think the best implementation would be to simply disable the robot if a joystick is disconnected, and to also require a power cycle to re-enable the robot. This would make sure that no bad data/timing error caused by the disable would make the robot behave erratically.

[Kevin Sevcik]

Originally Posted by willson.thomas

I think the best implementation would be to simply disable the robot if a joystick is disconnected, and to also require a power cycle to re-enable the robot. This would make sure that no bad data/timing error caused by the disable would make the robot behave erratically.

Problematic and probably overkill. How do you implement default code that doesn't need to be changed to run a robot if missing a joystick means the robot won't run? Plus, disabling the whole robot when a joystick read fails probably takes more work.

[willson.thomas]

Originally Posted by Kevin Sevcik

Problematic and probably overkill. How do you implement default code that doesn't need to be changed to run a robot if missing a joystick means the robot won't run? Plus, disabling the whole robot when a joystick read fails probably takes more work.

It would only disable the robot if a joystick, which would have been enumerated at the beginning, produces multiple bad reads in a row. This way it would only disable if a joystick went missing while it was running, it wouldn't check at boot. Or you could have it check for joysticks at boot, and simply have four boolean values that need setting.