Thread created automatically to discuss a document in CD-Media.
Modular Sub-Processing by: ZZII 527
Case Study: a quick and easy position controller using a dedicated PIC 16F877 to handle interrupts, feedback, and floating-point control calculations
EDIT: As it currently stands, the custom circuit described in this document violates rule R57 and R59 from 2006. I will attempt to revise it, but as of now it would be ILLEGAL FOR FIRST COMPETITION.
“Modular sub-processing” is probably not a real phrase in the technical world, because I made it up. It was the best way I could think of to describe the concept of using individual microprocessors for robot modules to take much of the computational burden off of the main processor, the Innovation First, Inc. Robot Controller (IFI RC). Some FIRST teams have already used this method with great success. This white paper will attempt to demystify some of this control strategy using the example of a simple modular position controller built for under $30. It is just one example, and I will purposely avoid going into too much detail on the control theory or programming specifics so that I can simply highlight the benefits of modular sub-processing in general. Hopefully, the programming contingent of other teams can use ideas from this article to develop modular control solutions to many other situations.
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.
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.
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.
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.