paper: Modular Sub-Processing

[ZZII 527]

Thread created automatically to discuss a document in CD-Media.

Modular Sub-Processing by ZZII 527

[ericand]

The setup described in the paper is interesting, but seems to violate custom circuit rule R59 (2006 rules) which says that custom circuits may not "Directly affect any output devices on the robot, such as ... supplying a PWM signal to a speed controller..."

We had a custom circuit (PIC) to monitor the rotational speeds of the ball shooter motors, but the hard part was figuring out a communication mechanism back to the RC so that it could make the PWM changes if the speed was too slow or too fast. If we could have had the PIC control the speed directly, we would have had much better control. As it was, the RC just got 2 bits for each motor, which it interpreted as {too fast, just right, too slow, unused state). The RC then adjusted the motor controlling PWM directly (thus in compliance with R59), based on the input from the custom circuit.

[ZZII 527]

Originally Posted by ericand

The setup described in the paper is interesting, but seems to violate custom circuit rule R59 (2006 rules) which says that custom circuits may not "Directly affect any output devices on the robot, such as ... supplying a PWM signal to a speed controller..."

We had a custom circuit (PIC) to monitor the rotational speeds of the ball shooter motors, but the hard part was figuring out a communication mechanism back to the RC so that it could make the PWM changes if the speed was too slow or too fast. If we could have had the PIC control the speed directly, we would have had much better control. As it was, the RC just got 2 bits for each motor, which it interpreted as {too fast, just right, too slow, unused state). The RC then adjusted the motor controlling PWM directly (thus in compliance with R59), based on the input from the custom circuit.

Thanks for bringing this up. That's a bit embarrassing...I should have read through the custom circuitry rules a bit more carefully, but I got caught up in what seemed like a cool idea. I have added a disclaimer to the paper description and will look into other ways to do it, although I would agree that it becomes a much harder challenge and much of the benefit is lost. It was still an interesting as a side-project, though.

[Dave Flowerday]

I think it would be prudent to put a big warning in this document that the device you describe is illegal for use in a FIRST competition.

*Well, we don't know for certain that it is illegal this year, but I'd be willing to bet money on it. It is a safety issue, plain and simple, to have a custom circuit device "in between" the RC's PWM output and the speed controller. It will totally defeat IFI's robot disable functionality.

[FourPenguins]

Originally Posted by Dave Flowerday

I think it would be prudent to put a big warning in this document that the device you describe is illegal for use in a FIRST competition.

*Well, we don't know for certain that it is illegal this year, but I'd be willing to bet money on it. It is a safety issue, plain and simple, to have a custom circuit device "in between" the RC's PWM output and the speed controller. It will totally defeat IFI's robot disable functionality.

Not only would it be a safety issue, but once teams are using different hardware, the formerly level playing field gets a bit bumpy...

[Jon236]

I also believe the unit, as configured, would be illegal under FRC rules. However, it would be simple to return the calculated output speed to an analog port, rather than produce a pulse for the PWM directly. The RC would then read this and adjust the PWM output accordingly under software control.

Jon Mittelman
Mentor
Team 236