Quote:
Originally Posted by Gdeaver
I don't think I made my point very well. The problem with the current RC is that it controls everything. Say your 2010 robot needs to have 6 victors and 6 motors. On 4 motors you want to have velocity and acceleration control all independent of each other. The motors - trans are coupled to encoders. The other 2 motors - trans need to control positioning and are coupled to potentiometers. The robot controller as it is now has a problem. There are not enough counters to handle the encoders.
|
Perhaps you
did make your point well, but nobody responded to it the way you expected because your point does not reflect the reality of the controller. I've successfully had the RC reading four quadrature encoders simultaneously, and I could have added two more if necessary, without using external hardware. The number of potentiometers is simply not important, as long as you don't exceed the number of analog inputs on the PIC.
Quote:
|
Even if you add external circuits to cut down on the number of counters the interrupt processing time increases. Each PID control loop takes time. Add to that the ADC time and other processing time, the controller is loaded up and the program is complex.
|
Complexity is not a major issue if all you're doing is duplicating existing components. That's what happens when you add more encoders or more PID-controlled motors. If you're programming your PID control well, all the "loops" take place at the same time, and the only thing to worry about is how much of that time is left to do other tasks. I've done a little measurement of PID processing time, and it's
not a problem with the current RC -- I believe it could handle as many separate PIDs as there are PWM outputs without getting anywhere close to running out of CPU cycles. The ADC time is already a non-issue if you set it up to do measurements in the background. I agree that you do have to watch out for interrupt service saturation, but choosing appropriate encoders will take care of almost all of that.