Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Question about encoders to control motor (http://www.chiefdelphi.com/forums/showthread.php?t=115921)

Vikingtech2054 09-04-2013 22:35

Question about encoders to control motor
 
Our team is competing this weekend at the Michigan State Championship, i have been the programmer for about the last two years and i look to improve our shooter. The way we control the speed of the shooter is working well but we look to improve it by adding an encoder. I have played around with encoders on an old robot i had played with them and understand how they work. Although i need help using the rpm from the encoder to control the shooter speed
I currently use Labview as a programming language
What i am looking for is an example or VI that will automatically adjust the speed of the shooter to the desired rpm by using the information from the encoder. (if its going fast enough or to fast). I have looked at some of the PID Vi's but i cant seem to find one that will work for the application im looking for. If you can help me or give me an example how to use the encoder to control the shooter that would be great. Thanks

nicholsjj 09-04-2013 22:43

Re: Question about encoders to control motor
 
I admire your passion for continuing to work on your code, but a word of caution is sometimes don't over-complicate things. I am directing you to this thread http://www.chiefdelphi.com/forums/sh...ight=Bang-bang to get started. It should get your feet off the ground. Know that your team has won two Michigan District Events so be careful when revamping code.

Chris Hibner 09-04-2013 22:47

Re: Question about encoders to control motor
 
We use a bang-bang controller very successfully. It is very simple:

1) decide on the RPM you want for your shooter. Let's call it DesiredRPM.

2) You have the RPM from your encoder. Call it ActualRPM.

3) Implement your LabVIEW code as follows:

if (ActualRPM < DesiredRPM)
MotorOutput = 1.0;
else
MotorOutput = 0;

The keys to this working well are:

1) Do NOT filter or use averaging of your RPM reading from your encoder.

2) Run it in the fast loop. We do it in a 30 ms loop and we get good results.

If you have any questions or want any help with setting it up or testing, come find me in our pit on Wednesday evening. I won't be at the competition during the day on Thursday and Friday (I'll be at work).

gluxon 09-04-2013 22:58

Re: Question about encoders to control motor
 
Quote:

Originally Posted by Chris Hibner (Post 1259584)
We use a bang-bang controller very successfully. It is very simple:

1) decide on the RPM you want for your shooter. Let's call it DesiredRPM.

2) You have the RPM from your encoder. Call it ActualRPM.

3) Implement your LabVIEW code as follows:

if (ActualRPM < DesiredRPM)
MotorOutput = 1.0;
else
MotorOutput = 0;

The keys to this working well are:

1) Do NOT filter or use averaging of your RPM reading from your encoder.

2) Run it in the fast loop. We do it in a 30 ms loop and we get good results.

If you have any questions or want any help with setting it up or testing, come find me in our pit on Wednesday evening. I won't be at the competition during the day on Thursday and Friday (I'll be at work).

This particular algorithm scares me a bit. Did your robot shooter motors have issues handling the stress of constantly reversing its rotation?

Ether 09-04-2013 23:09

Re: Question about encoders to control motor
 
Quote:

Originally Posted by Vikingtech2054 (Post 1259577)
...I have played around with encoders on an old robot i had played with them and understand how they work. Although i need help using the rpm from the encoder to control the shooter speed
I currently use Labview as a programming language
What i am looking for is an example or VI that will automatically adjust the speed of the shooter to the desired rpm by using the information from the encoder. (if its going fast enough or to fast)... If you can help me or give me an example how to use the encoder to control the shooter that would be great. Thanks

First things first:

- What model encoder are you using?

- What motor(s) are you using?

- What motor controller(s) are you using?

- What is the gear ratio from your motor output shaft to the shooter wheel?

- Where is you encoder mounted? (i.e. is it measuring the motor output shaft speed, or the wheel speed, or something in-between)

- How are you decoding the raw signal from the encoder? (i.e. do you have it set up as a counter or an encoder, and are you reading counts or period)

- What is your desired shooter wheel speed (aka "setpoint")

Answering those questions will improve your chances of getting correct advice.



Ether 09-04-2013 23:10

Re: Question about encoders to control motor
 
Quote:

Originally Posted by gluxon (Post 1259592)
Did your robot shooter motors have issues handling the stress of constantly reversing its rotation?

What do you mean by "constantly reversing its rotation" ?



billbo911 09-04-2013 23:16

Re: Question about encoders to control motor
 
Quote:

Originally Posted by gluxon (Post 1259592)
This particular algorithm scares me a bit. Did your robot shooter motors have issues handling the stress of constantly reversing its rotation?

This is classic Bang-Bang. Full power forward or coast. That's it. No reversing in that code at all.

friskywombat 09-04-2013 23:16

Re: Question about encoders to control motor
 
We use bang-bang on our shooter wheel, and it's working pretty amazingly. But instead of an encoder, we have an optical sensor that is rigged as a digital signal, and set up as a Counter object in LabVIEW. We have the code running every 5 milliseconds in one of LabVIEW's timed loops. The motor speeds back up to our desired RPM very quickly after a dropoff, and there is only a little oscillation when it reaches the RPM (not enough to affect the shot, even at full court). And Gluxon, we haven't had any problems with our CIM or Jaguar, even running the algorithm at 200 Hz.

gluxon 09-04-2013 23:24

Re: Question about encoders to control motor
 
Quote:

Originally Posted by billbo911 (Post 1259604)
This is classic Bang-Bang. Full power forward or coast. That's it. No reversing in that code at all.

I had a brain hiccup while reading that code. Last time I worked on robot code, it was with a servo motor where 0 was backwards, 1 was full forward, and 0.5 was stop (weird, yes). Either way, that code is stopping and starting the motor at what I would guess to be a very high rate. I'd imagine some mechanical stress depending on the motor used, no?

Ginto8 09-04-2013 23:33

Re: Question about encoders to control motor
 
Quote:

Originally Posted by gluxon (Post 1259592)
This particular algorithm scares me a bit. Did your robot shooter motors have issues handling the stress of constantly reversing its rotation?

If you have your speed controller jumpered into coast mode (there's a jumper labeled "BC" for brake/coast), you shouldn't be stressing anything. I implemented a Bang-Bang controller on last year's shooter wheel for testing, and made some very scary-sounding repeated thunks from the wheel, but I think that was a chain re-engaging more than anything. We didn't go for a Bang-Bang this season, instead opting for a PID controller. It has worked quite well, but it required some significant tuning. At our last competition, we retuned the controller a little, and shortened our initial spin-up time by about a second. We might be retuning it a bit this weekend as well. We'll see.

Ether 09-04-2013 23:34

Re: Question about encoders to control motor
 
Quote:

Originally Posted by gluxon (Post 1259611)
that code is stopping and starting the motor at what I would guess to be a very high rate.

The higher the rate, the better. The inertia of the wheel keeps the wheel speed steady in between command updates.

It's not starting and stopping. It's starting and coasting. One of the requirements of using bang-bang is that the motor controller jumper must be in the "coast" position.


Quote:

I'd imagine some mechanical stress depending on the motor used, no?
It might, if there is excessive mechanical free play between the motor shaft and the wheel. That's why I asked all those questions. Bang-bang works remarkably well, if you have the right mechanical design for it.



Ether 09-04-2013 23:37

Re: Question about encoders to control motor
 
Quote:

Originally Posted by friskywombat (Post 1259605)
We use bang-bang on our shooter wheel, and it's working pretty amazingly. But instead of an encoder, we have an optical sensor that is rigged as a digital signal, and set up as a Counter object in LabVIEW. We have the code running every 5 milliseconds in one of LabVIEW's timed loops. The motor speeds back up to our desired RPM very quickly after a dropoff, and there is only a little oscillation when it reaches the RPM.

Check to make sure your Jags are not jumpered for voltage ramping.



Ether 09-04-2013 23:40

Re: Question about encoders to control motor
 
Quote:

Originally Posted by Ginto8 (Post 1259615)
I implemented a Bang-Bang controller on last year's shooter wheel for testing, and made some very scary-sounding repeated thunks from the wheel, but I think that was a chain re-engaging more than anything.

Mechanical free play and bang-bang sometimes don't go together very well. Direct coupling of motor shaft to shooter wheel is more amenable to bang-bang control.



DjScribbles 09-04-2013 23:44

Re: Question about encoders to control motor
 
I'm not much help with Labview code specifically, but I can help you setup the control and explain the bang-bang controller to you a bit at MSC if you want some help. Just swing by our pit and ask for Joe.

Woolly 09-04-2013 23:48

Re: Question about encoders to control motor
 
Quote:

Originally Posted by Ether (Post 1259623)
Mechanical free play and bang-bang sometimes don't go together very well. Direct coupling of motor shaft to shooter wheel is more amenable to bang-bang control.



Yeah, the belt on our robot's shooter doesn't exactly like slamming between coast and full power. However the feed-forward we're doing is giving us rpm control that stays within ~10 RPM of the set-point, without being hard on the belt.


All times are GMT -5. The time now is 03:34.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi