OCCRA
Go to Post Turning is overrated - Allison [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #31   Spotlight this post!  
Unread 04-17-2012, 06:26 PM
billbo911's Avatar
billbo911 billbo911 is offline
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,856
billbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
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 2010 Creativity in Design winner, Sacramento 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 ($$$).
2013 Pow3rhou53 Pwnage Gracious Professionalism Award.
2014 2X Rockwell Automation: Innovation in Control Award (CVR and SAC). Curie Division, Gracious Professionalism Award.
Reply With Quote
  #32   Spotlight this post!  
Unread 04-17-2012, 09:11 PM
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,136
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
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).

Last edited by Tom Line : 04-17-2012 at 09:23 PM.
Reply With Quote
  #33   Spotlight this post!  
Unread 04-17-2012, 09:17 PM
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,136
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Ether View Post
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?
Reply With Quote
  #34   Spotlight this post!  
Unread 04-17-2012, 09:28 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
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?


Reply With Quote
  #35   Spotlight this post!  
Unread 04-17-2012, 09:52 PM
billbo911's Avatar
billbo911 billbo911 is offline
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,856
billbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond reputebillbo911 has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Tom Line View Post
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 2010 Creativity in Design winner, Sacramento 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 ($$$).
2013 Pow3rhou53 Pwnage Gracious Professionalism Award.
2014 2X Rockwell Automation: Innovation in Control Award (CVR and SAC). Curie Division, Gracious Professionalism Award.
Reply With Quote
  #36   Spotlight this post!  
Unread 04-17-2012, 10:15 PM
Chris Hibner's Avatar Unsung FIRST Hero
Chris Hibner Chris Hibner is offline
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,404
Chris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond repute
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.
Reply With Quote
  #37   Spotlight this post!  
Unread 04-17-2012, 10:22 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
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.


Reply With Quote
  #38   Spotlight this post!  
Unread 04-17-2012, 10:34 PM
Chris Hibner's Avatar Unsung FIRST Hero
Chris Hibner Chris Hibner is offline
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,404
Chris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond repute
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.
Reply With Quote
  #39   Spotlight this post!  
Unread 04-17-2012, 10:39 PM
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,136
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
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.
Reply With Quote
  #40   Spotlight this post!  
Unread 04-17-2012, 10:42 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by Chris Hibner View Post
(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.


Reply With Quote
  #41   Spotlight this post!  
Unread 04-18-2012, 12:27 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
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

Reply With Quote
  #42   Spotlight this post!  
Unread 04-18-2012, 02:17 PM
mjcoss mjcoss is offline
Registered User
FRC #0303
 
Join Date: Jan 2009
Location: Bridgewater,NJ
Posts: 69
mjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the rough
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 View Post

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

Reply With Quote
  #43   Spotlight this post!  
Unread 04-18-2012, 03:01 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: paper: Shooter Wheel Speed Control

Quote:
Originally Posted by mjcoss View Post
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.
Reply With Quote
  #44   Spotlight this post!  
Unread 04-18-2012, 05:07 PM
mjcoss mjcoss is offline
Registered User
FRC #0303
 
Join Date: Jan 2009
Location: Bridgewater,NJ
Posts: 69
mjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the roughmjcoss is a jewel in the rough
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 View Post
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.


Reply With Quote
  #45   Spotlight this post!  
Unread 04-18-2012, 08:24 PM
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 6,069
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
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.


Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

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


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

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


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