Speed Controller

I was wondering how many teams are using a speed controller, either on the drive or the tube manipulator. If you are how do you go about doing it? I just am curious as to how other teams handle a speed controller. I might be able to post my code later, when it’s finished.

I can’t program but I do know that you have to use a speed controller to control any CIM’s and / or Fisher Price Motors on your robot this year.

I meant like accurately controlling speed with Encoders and software. In other words using a closed loop speed controller. Sorry for the confusion.

As far as I am concerned, you HAVE to use a speed controller on each of your motors like Hellfeier675 said. With that being said, we are using Jaguars and the CANBus system. You can also use PWMs to the Jaguars or Victors to controller the motors.

Gotcha, sorry. Our programmers have been working with the encoders for a while now and it took them some time to get it to stop tweaking on them. I’ll talk to them and see what they have in terms of helpful information!

What you’re thinking of is called PID - proportion, integral, derivative. It’s not too hard to use - you (essentially) give it an encoder (where you are) and the desired position (where you want to be) and that calculates an error. The PID controller’s purpose is to try to get that error to zero as fast as possible. You also have to put in some tuning parameters, which is just trial and error. Look it up on wikipedia, it’s good information.

Closed loop, or feedback, control system is the right term. Proportional, integral, and derivative refer to types of error signals that can be calculated from a feedback signal. A PID controller is one type of closed-loop controller, albeit the most used, but there are other types.

To respond to the original question, 1708 is using a feedback control system for our autonomous; of course, the bang-bang controller that we’re using is not the most elegant, but it’s what we can do with digital line sensors. No controllers for any manipulators or anything, though. If we were using an arm, though, we’d definitely create one.


Closed-loop velocity control (with PID) is a bit more complicated. For example, if you tune the loops on a cart, it doesn’t mean the robot will be tuned on the floor under weight. Additionally, the coefficients represent different things because velocity is already a derivative. Check out this thread:

What do we use?

Drivetrain: We have integrated P control (implemented like I) for drive velocity. We have some special handling for special cases, to fix annoyances in the 20% of situations where the I controller works worse than a human.

Camera: We have a P controller to position.

Mechanisms: We run a P position controller for our motors, and also have a basic on/off controller for window motor mechanisms on Spikes. Depending on how it handles, we might implement D and/or a gain scheduler.

Autonomous: We run a P controller to distance (on each side) or a P controller to heading, depending on autonomous command. The output of either is fed to the P velocity controller above. We do not use the line sensors at all.

Tuning: We determined the highest speed of the slowest side on the ground in both directions in each gear (a total of 4 tuning constants), since the slower side determines the maximum top speed. We have separate sets of gains for each gear, and there are 3 tuning constants (used by the gain scheduler).

Actually, we have 11 motors on our robot. 10 of them have some sort of feedback control on them (velocity or position), and the last has a state-machine controller but no velocity or position control. We like easy, automated control.