Controlling Motor Turns Autonomous

Hey all. Just a quick question. When not using encoders, can you control how many revolutions your motor should turn during an autonomous period, or do you have to control them using time specifications?

Also, how can I program autonomous to automatically switch to teleop when 15 seconds has happened?

You can control just about anything you can measure. To control the number of revolutions of a shaft, you need to measure the shaft revolutions. That’s something encoders are good at. What kind of motor is it, what kind of gearbox are you using, and what is it connected to?

Your program does not control whether the robot is in Autonomous or Teleoperated mode. That’s done by the Driver Station, and on a competition field the Driver Station is told to command the appropriate mode at the appropriate time by the Field Management System.

You can use “practice mode” on the Driver Station to run it through a timed sequence of disabled, autonomous, teleoperated, and disabled again. If you want to, you can modify the timing on the DS setup tab.

We’re using these encoders: http://www.andymark.com/product-p/am-0180.htm

I’d like to use them on our drive train during autonomous (which has no gearbox (it’s just a cim on each side)), and on our lead screw lift mechanism during teleop to hit various levels.

I’ve looked at some previous posts about encoders, and also at the Team 358 example, but I’m still a little lost at how to program and/or mount them.

You’re probably not going to be too happy with that arrangement.

Have you confirmed that you can drive without tripping the 40 amp breakers?

The Encoder example in LabVIEW shows how to wire and how to program them.

The am-0180 is designed to be attached to one of several specific gearboxes, or to a custom gearbox with the same short 1/4" shaft and mounting hole pattern. Mounting it is going to be rather problematic without such a gearbox.

I may be incorrect with my assessment of the gearbox. It’s not similar to what we had last year, which I know to be a gearbox, so I might have made that assumption too soon. I’ll post a picture in the morning. Thanks!

These two pictures sorta show what I’m working with.









The longitudinal axis of your CIM is clearly not concentric with the wheel axis. So there are some gears involved.

You’re right Ether. I’m sorry…I’m not the most mechanically minded member of the team. I’ve got someone mounting the encoder on an axle right now. I’m hoping to use it to control the motors during autonomous, but I’m not so sure what to do next. I’m going to try and use the Motor with Encoder example included with Labview, but it looks to me as if that gives me encoder information, not actual ways to affect the motors with that information. Not so sure really. I also have read something about PID. Where do I implement that?

If the motor and the encoder are both mechanically linked to the gearbox, then the encoder can give information about the motor.

To get a jump-start to understanding PID, you may find the following YouTube video quite helpful:

Others can help you with LabVIEW implementation details.

That video did help. Thanks! Anyone have advice about labview implementation?

Here is some example code of how one might implement a PID gain on the encoder to drive the robot in auto. Please refer to the a fore posted video for how to set the gains. Also, please ignore the comments before the sequence, they were just not deleted from the default auto.

Also, the stopped constants will likely need adjusted - it is .3 on our robot.

There are other options, like running the pid loop in parallel, and setting the instructions in the sequence (i.e. not in the loop with the pid), using a stacked sequence, or the array of actions that comes with the default auto (although you will likely want to change the contained cluster to contain a distance rather than a joystick y), although be careful to put a wait inside the parallel loop so it doesn’t bog down the processor.

It could be argued that constantly resetting the encoders allows for more drift (inconsistent drive due to not hitting the set point exactly, and I would agree, it would be better to use absolute set points (in this example, 500, 1100, and 1600).

As far as automatically switching to Teleop, it is not appropriate to code it to (since that would require messing with how the robot decides with mode to drive), but you can run the driver station in practice mode, and with the settings correct, it will do this (i.e. 15s auto 0s delay between periods).





Thank you very much! That looks like it’ll be a lot of help. I’ll try to integrate it.

Thanks again!