Tragedies happened. We've learned from them, as individuals, as teams, as a community. - Taylor [more]
 Chief Delphi paper: Shooter Wheel Speed Control
 Team 51 CD-Events CD-Media CD-Swap CD-Spy FRC-Spy Unsung FIRST Heroes WFA
The Chief Delphi Forums are sponsored by Innovation First International, Inc.

#31
04-17-2012, 06:26 PM
 billbo911 Registered User AKA: That's "Mr. Bill" FRC #2073 (EagleForce) Team Role: Mentor Join Date: Mar 2005 Rookie Year: 2005 Location: Elk Grove, Ca. Posts: 1,614
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Ether I should have been clearer: The "low_command" is a tuning constant, not the target speed, and was not intended to be so low that it tops out at a speed below the "spinup_speed". "low_command" should be high enough that it briskly accelerates up to (and beyond) spinup_speed, at which point the full voltage is applied. Many shooter wheel setups can handle application of full voltage to the motor even at zero RPM, but some can't. It's a function of the gear ratio and the wheel inertia and the motor being used. For such setups, simply set spinup_speed=0.0 The code I posted was for those shooter setups that can't handle a full 12 volts being applied at zero RPM, but could, for example, handle, say, 8 volts at zero RPM and 12 volts at 1000 RPM. For that example, you would set spinup_speed to 1000 RPM and low_command to 8 volts. Simple, and gets the job done. With the code I posted, the minimum continuous RPM is simply commanded as the target speed by each team's software to whatever they want it to be, and the code I posted will bang-bang regulate at that speed. That target speed can be zero if the team so desires. For really finicky setups (e.g. high inertia wheel, not much gear ratio), you could always add a third "else" statement: Code: ```if (measured_speed >= target_speed) motor_command = 0.0; else if (measured_speed >= spinup_speed) motor_command = 1.0; else if (measured_speed >= medium_speed) motor_command = medium_command; else motor_command = low_command;```
Got it. So, in essence, you want the absolute maximum acceleration possible, for the particular shooter design, that it can handle without tripping the over-current.

With the version I added today, you can set the trip point for low to high acceleration as well as the rate of slew rate limiter. By tuning these two, you can achieve almost exactly what you are describing. The only difference is the start up voltage will be a ramp, with an adjustable slope, instead of a step from 0v. Granted, it is not the absolute fastest acceleration you can get, but I doubt the differences will be noticeable in actual performance. You will see it on a scope, but that's pretty much it. I'm guessing a only few millisecond difference between the two designs from 0 RPM to target RPM in the 2500-4000 range.
__________________
So long and thanks for all the fish!

CalGames 2009 Semi Finalist, CalGames 2009 Autonomous Champion Award winner
Sacramento/Davis 2010 Creativity in Design winner, Sacramento/Davis 2010 Quarter finalist
2010 Madtown Creative Design Award, 2011 Sacramento Finalist, 2011 Madtown Engineering Inspiration Award,
2012 Sacramento Semi-Finals, 2012 Sacramento Innovation in Control Award, 2012 SVR Judges Award.
2012 CalGames Autonomous Challenge Award winner (\$\$\$).
#32
04-17-2012, 09:11 PM
 Tom Line Autonomouse FRC #1718 (The Fighting Pi) Team Role: Mentor Join Date: Jan 2007 Rookie Year: 1999 Location: Armada, Michigan Posts: 1,876
Re: paper: Shooter Wheel Speed Control

I'm interested in teams claiming +/- 15 rpm accuracy.

We've implemented robust PID control, and today implemented bang-bang control as a second option.

We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM.

The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM.

The best the PID loop could do completey unfiltered was arond +/- 80 RPM.

The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds.

I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems.

Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).
__________________
Team 1718 LabView Tutorial

Last edited by Tom Line : 04-17-2012 at 09:23 PM.
#33
04-17-2012, 09:17 PM
 Tom Line Autonomouse FRC #1718 (The Fighting Pi) Team Role: Mentor Join Date: Jan 2007 Rookie Year: 1999 Location: Armada, Michigan Posts: 1,876
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Ether Thank you for posting the data. Would you mind posting the following additional information please? - what motor(s) - total gear ratio from motor to wheel(s). - what type and diameter wheel(s)? - Jag or Vic? - coast or brake mode? - voltage ramp rate? symmetric or up only? - what encoder model, and where mounted - what language - 1x 2x or 4x decoding? - Counter or Encoder class?- to measure RPM, are you measuring the time between consecutive counts, or are you dividing the counts by the delta time? - if dividing counts by delta time (see above item), how are you computing the delta time - encoder signal not filtered? - what execution cycle update rate? PS: You have some interesting noise on your sensor signal. Look at cells B57 & B58 for example.
Is there any specific reason to use a counter class rather than encoder class?
__________________
Team 1718 LabView Tutorial
#34
04-17-2012, 09:28 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Tom Line Is there any specific reason to use a counter class rather than encoder class?
For the shooter wheel application, you don't need the extra channel for direction. Less wiring, frees up a channel on the DS.

Just curious: did you try using the encoder as described on pages 1 & 2 in revA of the paper?

#35
04-17-2012, 09:52 PM
 billbo911 Registered User AKA: That's "Mr. Bill" FRC #2073 (EagleForce) Team Role: Mentor Join Date: Mar 2005 Rookie Year: 2005 Location: Elk Grove, Ca. Posts: 1,614
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Tom Line I'm interested in teams claiming +/- 15 rpm accuracy. We've implemented robust PID control, and today implemented bang-bang control as a second option. We tried 4 different high speed encoders, 2 bourn, 1 grayhill, and 1 honeywell. The noise in our 'best' situation (completely unfiltered running off the get rate from the encoder, encoder set to 1x decoding, get rate in a timed loop of 10ms) was +/- 60 RPM. The best the bang-bang loop could do completely unfiltered was around +/- 100 RPM. The best the PID loop could do completey unfiltered was arond +/- 80 RPM. The PID loop spins up in 3 seconds. The bang-bang in about 1.5 seconds. I'm curious what teams are using to measure their system to gain +/- 15 RPM accuracy without noise problems. Should we be using an IIR or moving average filter to filter the incoming rate from the encoder to minimize noise effect on the bang-bang? (That's the geekiest sentence I've typed in a long time).
Ether pointed this out to me. Using the "Wait" timing loops is not as reliable for timing events as you might think. Read this paper call Timing is everything by team 358.
I truly believe you can get much more reliable rate control simply by switching to a "Timed Structure" instead of a "Wait" loop.
__________________
So long and thanks for all the fish!

CalGames 2009 Semi Finalist, CalGames 2009 Autonomous Champion Award winner
Sacramento/Davis 2010 Creativity in Design winner, Sacramento/Davis 2010 Quarter finalist
2010 Madtown Creative Design Award, 2011 Sacramento Finalist, 2011 Madtown Engineering Inspiration Award,
2012 Sacramento Semi-Finals, 2012 Sacramento Innovation in Control Award, 2012 SVR Judges Award.
2012 CalGames Autonomous Challenge Award winner (\$\$\$).
#36
04-17-2012, 10:15 PM
 Chris Hibner Eschewing Obfuscation Since 1990 AKA: Lars Kamen's Roadie FRC #0051 (Wings of Fire) Team Role: Engineer Join Date: May 2001 Rookie Year: 1997 Location: Canton, MI Posts: 1,298
Re: paper: Shooter Wheel Speed Control

Tom,

We're using Victor speed controllers and running the controller in a 30 ms timed loop. We are using a high-quality internal ball-bearing encoder (can't remember the brand), 32 counts per rev, 1x decoding. No filtering on the encoder signal going into the bang-bang controller.

Our shooter logic uses a single pole IIR filter at about 0.5 Hz on the encoder signal. The output of the IIR filter shows noise of about +/- 15-20 RPM. The mean appears to be right at our desired speed. Our practice robot with a really bad gearbox was about 50 RPM less than the desired speed.

I haven't done a data log to actually calculate the mean and noise level with our competition robot, but it looks really good. Our shooter logic requires the filtered shooter speed to be within 30 RPM for more than 4 consecutive samples before we'll shoot a ball. We do have data logging for each shot and shooter speed has not been an issue for delaying shots (aim is usually the long lead time).

The biggest upside we found when switching to this control method is getting the shooter to slow quickly. When we were using PID, shooter speed was often delaying shots, especially if we enabled the shooter and then moved closer to the goal. The I term was always adding some power to the motor which delayed the slow down time. The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).
__________________
-
An ounce of perception is worth a pound of obscure.

Last edited by Chris Hibner : 04-17-2012 at 10:19 PM.
#37
04-17-2012, 10:22 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Chris Hibner The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).
... or use brake mode instead of coast mode. This will slow you down real quick. But things may get too hot.

#38
04-17-2012, 10:34 PM
 Chris Hibner Eschewing Obfuscation Since 1990 AKA: Lars Kamen's Roadie FRC #0051 (Wings of Fire) Team Role: Engineer Join Date: May 2001 Rookie Year: 1997 Location: Canton, MI Posts: 1,298
Re: paper: Shooter Wheel Speed Control

Ether makes a good point. You'll probably also find your final speed to be less than your desired speed if you use brake mode (see my comment above on our practice robot with the bad gearbox - extra friction caused the actual speed to be less than the desired speed).

A couple of more things to note:

1) Originally, we accidentally hooked up the output of our IIR filter to the bang-bang controller "actual speed" input. The results were not very good. The shooter speed oscillated quite a bit. When you think about it, the oscillations make sense: the phase delay of the IIR filter made the controller stay at 1.0 for too long even if the actual instantaneous speed dictated that the power be 0.0 (or vice versa).

2) Speed controller resolution: Consider that a Victor speed controller has 254 discrete output states (two states are reserved). If the top speed of your shooter is about 5000 RPM (for a shot from the bridge), the best resolution you can do with a constant power command is about 20 RPM (imagine if your PID controller output a very nice steady PWM command). However, if your PWM command dithers the right amount, you can gain resolution on your shooter speed. Don't believe me? Just consider that we're getting tons of resolution to control various speeds just based on commanding 1's and 0's to the power. (I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.). Anyway, that extra dithering of the output is why I advocate not filtering the encoder signal input to the bang-bang controller.
__________________
-
An ounce of perception is worth a pound of obscure.
#39
04-17-2012, 10:39 PM
 Tom Line Autonomouse FRC #1718 (The Fighting Pi) Team Role: Mentor Join Date: Jan 2007 Rookie Year: 1999 Location: Armada, Michigan Posts: 1,876
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Chris Hibner Tom, We're using Victor speed controllers and running the controller in a 30 ms timed loop. We are using a high-quality internal ball-bearing encoder (can't remember the brand), 32 counts per rev, 1x decoding. No filtering on the encoder signal going into the bang-bang controller. Our shooter logic uses a single pole IIR filter at about 0.5 Hz on the encoder signal. The output of the IIR filter shows noise of about +/- 15-20 RPM. The mean appears to be right at our desired speed. Our practice robot with a really bad gearbox was about 50 RPM less than the desired speed. I haven't done a data log to actually calculate the mean and noise level with our competition robot, but it looks really good. Our shooter logic requires the filtered shooter speed to be within 30 RPM for more than 4 consecutive samples before we'll shoot a ball. We do have data logging for each shot and shooter speed has not been an issue for delaying shots (aim is usually the long lead time). The biggest upside we found when switching to this control method is getting the shooter to slow quickly. When we were using PID, shooter speed was often delaying shots, especially if we enabled the shooter and then moved closer to the goal. The I term was always adding some power to the motor which delayed the slow down time. The bang-bang controller completely cuts the power in this case so the slow down can't really be any faster, unless you apply negative power (which probably isn't a great idea).
That explains a decent amount.

We've been using the unfiltered signal, which is fairly noisy. Filtering that should bring it more inline. I'll try that tomorrow with our moving average filter and try a bang-bang again.

Our encoders are all 128 counts per revolution, but they are geared so that we get 55 counts per shooter revolution.

We are using the timed structure set at a 10ms loop rate in periodic tasks (not a while loop with a wait). We did not see much of an improvement moving to a timed structure because our cpu utilization is usually around 70% and our periodic loops have been running fairly consistently (we flag an error message on our driverstation LCD whenever they get too far out of whack).

To give you an idea, we were using a check of +/- 100 rpm for 4 consecutive counts and still getting good distance accuracy from the key. That tells me that our actually speed is fairly accurate, but the noise is masking it. The filter should help.
__________________
Team 1718 LabView Tutorial
#40
04-17-2012, 10:42 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by Chris Hibner (I actually submitted a white paper on this topic a number of years ago, which makes me especially upset with myself that I didn't think of this type of controller until Martin mentioned it. Grrr.)
I feel your pain. I wrote a paper on it when I was in grad school back in the early '70s.

#41
04-18-2012, 12:27 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?
a) at t=0, send a request to the Jag via CAN for a speed signal
b) at t=t1, receive the requested speed signal from the Jag via CAN
c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN
d) at t=t3, the Jag receives the new command

#42
04-18-2012, 02:17 PM
 mjcoss Registered User FRC #0303 Join Date: Jan 2009 Location: Bridgewater,NJ Posts: 69
Re: paper: Shooter Wheel Speed Control

We have the setup that you're looking for, and I'd be willing to run the test. I'm just not sure how to collect the test data. Do you know if the elapse time for a command is just when the "SetSpeed()" function returns?

So that
t1 = GetClock();
jag->SetSpeed(500);
t2 = GetClock();
elapse time = t2 -t1

Or are you looking for something more complicated? We're currently running the PID loop on the Jaguar, and I'd wish I'd seen this earlier. I might have changed what we were doing as this looks like it might get us what we wanted without the headaches of the PID controls on the Jaguars.

Quote:
 Originally Posted by Ether For a setup with the shooter wheel speed sensor (encoder) plugged directly into the Jag, could some please estimate (or better yet provide test data for) the elapsed times (t1, t2, t3) for the following sequence of events?a) at t=0, send a request to the Jag via CAN for a speed signal b) at t=t1, receive the requested speed signal from the Jag via CAN c) at t=t2, send a new command (based on the speed signal) to the Jag via CAN d) at t=t3, the Jag receives the new command
#43
04-18-2012, 03:01 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

Quote:
 Originally Posted by mjcoss So that t1 = GetClock(); jag->SetSpeed(500); t2 = GetClock(); elapse time = t2 -t1
Thanks for the offer.

No, the elapsed times I am looking for are:

dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back

dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag

dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command.

If you aren't doing all three operations in the same execution cycle, please mention that too.

If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.

Last edited by Ether : 04-18-2012 at 03:05 PM.
#44
04-18-2012, 05:07 PM
 mjcoss Registered User FRC #0303 Join Date: Jan 2009 Location: Bridgewater,NJ Posts: 69
Re: paper: Shooter Wheel Speed Control

The question is how to get at that information and what kind of accuracy are you looking for. Note that we are using C++, so ...

GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.

dt2 is a bit trickier. We aren't using your speed control method but rather are running the PID loop on the Jaguar. Each time through our TeleopPeriodic loop, we update the set point. Our periodic loop will do some work if no packet arrives from the driver station, but for the most part we update based on the arrival of new data from the driver station. We don't check to see what the set point currently is, we just reset it to the requested value.

dt3 is even trickier, if not unknowable. Again we could use the total round trip time of the Set() command which is used to register the current set point, but that includes the time to the Jaguar, and the return ack across the CAN bus, and thru the 2CAN and back up the ethernet stack and to the CANJaguar module.

Finally there is a lot of checking that I've added to around the Set() operation. Every Set() is followed by a CAN bus message requesting the fault status of the Jaguar, and then a CAN bus message requesting the PowerCycled flag. If a brown out occurred then the Jaguar configuration is reloaded.

When I get a chance I think I'll implement you're speed controller and see how it does relative to running the PID on the Jaguars as we currently are doing.

Quote:
 Originally Posted by Ether Thanks for the offer. No, the elapsed times I am looking for are: dt1: how long does it take from the time you ask the Jaguar what the motor speed is, to the time you read the answer that comes back dt2: how long does it take from the time you read the answer, to the time your code sends a new command to the Jag dt3: how long does it take from the time you send a new command to the Jag, to when it receives the command. If you aren't doing all three operations in the same execution cycle, please mention that too. If you aren't reading the speed from the Jag and sending a new command based on that speed, you would have to add that code to get what I'm looking for.
#45
04-18-2012, 08:24 PM
 Ether systems engineer (retired) no team Join Date: Nov 2009 Rookie Year: 1969 Location: US Posts: 4,598
Re: paper: Shooter Wheel Speed Control

Quote:
 GetSpeed() returns the current measured encoder speed as reported from the Jaguar. So the total round trip time can be gotten from grabbing the time before and after the call. This is, of course, not very fine grain and includes the time spent being packaged in an Ethernet frame, going to the 2CAN, being unpackaged, put on the CAN bus, out to the Jaguar, and back again.
This is what I'm looking for, because this elapsed time (or perhaps half of it) causes phase lag in the process variable. If you could run this one test it would be helpful.

 Thread Tools Display Modes Rate This Thread Linear Mode Rate This Thread: 5 : Excellent 4 : Good 3 : Average 2 : Bad 1 : Terrible

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Announcements     User Announcements FIRST     General Forum         FIRST E-Mail Blast Archive     Rumor Mill     Career     Robot Showcase     Moderated Discussion Technical     Technical Discussion     Robotics Education and Curriculum     Motors     Electrical         CAN     Programming         NI LabVIEW         WindRiver C++         Java         MATLAB & Simulink         Python     intelitek easyC/REC information         easyC v2 for Vex         easyC for FRC         REC/Learnmate         WPILib         easyC PRO     Control System         IFI Control System         FRC Control System         Sensors         USB Chicklet     Pneumatics     Kit & Additional Hardware     CAD         Inventor         SolidWorks         Pro ENGINEER / Creo     IT / Communications         3D Animation and Competition         Website Design/Showcase         Videography and Photography         Computer Graphics     National Instruments LabVIEW and Data Acquisition         LabView and Data Acquisition Competition     Awards         Chairman's Award     Rules/Strategy         Scouting         You Make The Call     Team Organization         Fundraising         Starting New Teams         Finding A Team         College Teams     Championship Event     Regional Competitions     FIRST in Michigan     Mid-Atlantic Robotics     Off-Season Events         Chief Delphi Invitational     Thanks and/or Congrats     FRC Game Design     OCCRA         OCCRA Q&A         OCCRA Programming Other     Unsung FIRST Heroes     Chit-Chat         Games/Trivia             Fantasy FIRST     Car Nack's Corner     College & University Education     Dean Kamen's Inventions     FIRST-related Organizations         Western Region Robotics Forum         Robot Chicks Union (RCU)         Southern California Regional Robotics Forum         Hearing-Impared Network         FIRST Interactive Rural SupporT         freelanceFIRST         FIRST Scouting Network         openFIRST         The Grand FIRST Team         FloridaFIRST         Inspiration Foundation Inc.         South Dakota FIRST         FIRST International Partners         FIRSTwiki         Ultimate Robot Challenge         East Coast Drivers Union         Team San Diego         CollegiateFIRST         Dream FIRST         FIRST Brasil         The Blue Alliance             Video Archives     FIRST Historians     FIRST-A-Holic's Anonymous Mailbox     FIRST In the News...     FIRST Lego League         Lego Mindstorm Discussion     FIRST Tech Challenge         FTC E-Mail Blast Archive     VEX         VEX Robotics Competition     Televised Robotics     Math and Science         NASA Discussion ChiefDelphi.com Website     CD Forum Support         Bulletins and Newsletters     Extra Discussion Old Forum Archives     1999     2000     2001

All times are GMT -5. The time now is 06:05 PM.

The Chief Delphi Forums are sponsored by Innovation First, Inc.

 -- English (12 hour) -- English (24 hour) Contact Us - Chief Delphi - Rules - Team Site - Archive - Top