Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Elevator Motion Profiling / PID Ramping (http://www.chiefdelphi.com/forums/showthread.php?t=135370)

Aero 02-03-2015 17:21
Elevator Motion Profiling / PID Ramping
 
Our elevator is way too fast.

We're currently using a standard PID loop, but it accelerates ridiculously quickly and throws totes.

I've looked into motion profiling, but can't see an easy way to (quickly) dynamically generate profiles between two arbitrary points on our elevator.

Is motion profiling the best solution here, or is there a simpler way to stop our elevator from accelerating too fast?

eddie12390 02-03-2015 17:22
Re: Elevator Motion Profiling / PID Ramping
 
If you're using CAN Talons, you can use the built-in voltage ramping.

Aero 02-03-2015 17:23
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by eddie12390 (Post 1452348)
If you're using CAN Talons, you can use the built-in voltage ramping.
We're using the 2015 Victors, so no built-in ramping there.

eddie12390 02-03-2015 17:26
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Aero (Post 1452349)
We're using the 2015 Victors, so no built-in ramping there.
Ether has a lot of information about motion profiling here: http://www.chiefdelphi.com/media/papers/3107. If you haven't seen it, it would be a good starting point. I know for sure that the Cheesy Poofs used trapezoidal motion profiles for their 2011 robot so it may be a good place to find an example. (https://github.com/Team254/FRC-2011)

Bluman56 02-03-2015 17:27
Re: Elevator Motion Profiling / PID Ramping
 
Did you attempt to lower the P (gain) value of your PID loop?

Aero 02-03-2015 17:31
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by eddie12390 (Post 1452351)
Ether has a lot of information about motion profiling here: http://www.chiefdelphi.com/media/papers/3107. If you haven't seen it, it would be a good starting point. I know for sure that the Cheesy Poofs used trapezoidal motion profiles for their 2011 robot so it may be a good place to find an example. (https://github.com/Team254/FRC-2011)
I read the Motion Profiling whitepaper, looked through the Poof's 2011 Github, and also read through 236's 2015 code. All the motion profiling I can find involves drivetrain stuff, which is between static values. Nothing that'll let you move between non-predefined setpoints.

Quote:
Originally Posted by Bluman56 (Post 1452352)
Did you attempt to lower the P (gain) value of your PID loop?
That will provide slower acceleration, but won't help the deceleration because our integral term will take over.

JABot67 02-03-2015 17:31
Re: Elevator Motion Profiling / PID Ramping
 
You could try:

- Open loop speed control on the elevator, such as connecting the Y axis of an operator joystick directly to the elevator motor output

- Closed loop speed control on the elevator (instead of position control), such as using the Y axis of an operator joystick as the setpoint to a (rate/speed control) PID controller which controls the motor

- Limiting the maximum output of the PID controller using SetOutputRange (float mimimumOutput, float maximumOutput)

- Motion profiling

Honestly, the open loop control might be enough. It's basically closed loop control given that the operator can look at the position of the elevator from the driver station to determine if it's moving too fast. If you are trying to do this in autonomous, though, obviously you have to use some sort of closed loop control. Limiting the maximum output of the PID controller may be a good idea in that case.

Aero 02-03-2015 17:34
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by JABot67 (Post 1452356)
You could try:

- Open loop speed control on the elevator, such as connecting the Y axis of an operator joystick directly to the elevator motor output

- Closed loop speed control on the elevator (instead of position control), such as using the Y axis of an operator joystick as the setpoint to a (rate/speed control) PID controller which controls the motor

- Limiting the maximum output of the PID controller using SetOutputRange (float mimimumOutput, float maximumOutput)

- Motion profiling

Honestly, the open loop control might be enough. It's basically closed loop control given that the operator can look at the position of the elevator from the driver station to determine if it's moving too fast. If you are trying to do this in autonomous, though, obviously you have to use some sort of closed loop control. Limiting the maximum output of the PID controller may be a good idea in that case.
Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.

JABot67 02-03-2015 17:46
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Aero (Post 1452358)
Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.
Closed loop speed control should allow you to set the speed to whatever you want it to be. You could make it so that it takes 4 seconds or 8 seconds or 16 seconds to go from bottom to top.

Open loop speed control allows your driver/operator to control the elevator's up/down motion directly (at least during teleop). This means that the operator can theoretically make sure the elevator isn't going too fast.

Of course the downside of these options is that it's hard to have position setpoints (ground, 1tote, 2totes, etc) but if you're just trying to get your elevator to stop throwing totes they probably would work.

Motion profiling would be an excellent next step if you think it's both important to have preset positions for the elevator (thus requiring position control) and use the max translation speed of your elevator during the travel time between positions. Downside, of course, is that it's harder to program.

Jefferson 02-03-2015 17:58
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Aero (Post 1452347)
Our elevator is way too fast.

We're currently using a standard PID loop, but it accelerates ridiculously quickly and throws totes.

I've looked into motion profiling, but can't see an easy way to (quickly) dynamically generate profiles between two arbitrary points on our elevator.

Is motion profiling the best solution here, or is there a simpler way to stop our elevator from accelerating too fast?
We used a pretty simplistic approach to ramping/position control this year:

First, capture the time the new setpoint was set (rampStartTime)

ramp = rGain*(GetClock() - rampStartTime)
output = error*ramp
constrain output in a reasonable range for the current load

Adjust the rGain to get the ramp up you want and the constraints to limit the top end.

Aero 02-03-2015 17:59
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by JABot67 (Post 1452365)
Closed loop speed control should allow you to set the speed to whatever you want it to be. You could make it so that it takes 4 seconds or 8 seconds or 16 seconds to go from bottom to top.

Open loop speed control allows your driver/operator to control the elevator's up/down motion directly (at least during teleop). This means that the operator can theoretically make sure the elevator isn't going too fast.

Of course the downside of these options is that it's hard to have position setpoints (ground, 1tote, 2totes, etc) but if you're just trying to get your elevator to stop throwing totes they probably would work.

Motion profiling would be an excellent next step if you think it's both important to have preset positions for the elevator (thus requiring position control) and use the max translation speed of your elevator during the travel time between positions. Downside, of course, is that it's harder to program.
I've already been through this train of thought, and motion profiling really is what we want. How inefficient would it be to generate a new motion profile every time we change setpoints?

Jared 02-03-2015 18:06
Re: Elevator Motion Profiling / PID Ramping
 
I have two ideas that might help
If you want to stick with plain PID, you could try just increasing the value of kD. If it starts to oscillate a lot, try a low pass filter (moving average over 0.1 seconds or so) on the sensor value. This will help slow the elevator, but it may not be enough.

A second solution is a nested PID controller (sometimes called cascade). Have the output of one PID controller be the input of the other.

Your first PID controller looks at the actual elevator position and the desired elevator position, and outputs a desired lift rate - not motor power.

The second PID controller takes this desired lift rate as an input, looks at the actual lift rate, and adjusts elevator lift motor power.

To tune, you first worry about the second PID controller that takes velocity as an input. To tune, you can set it up so that the operator sets a desired lift rate, and the elevator moves at this rate. Make sure all your units are in terms of velocity for this loop and you should have mainly kI for this loop, and no kP. You may want to also try having a feedforward term here, I believe WPI has this built in.

Next, you tune the second PID controller. This should have lots of kD, which will give you the smooth deceleration and dampening you want.

AdamHeard 02-03-2015 18:11
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Aero (Post 1452358)
Any sort of speed control won't really work, because our elevator is really fast. It's about 0.75 seconds from bottom to top.
We have limited the max output of our PID controller, but that only provides a max speed, and no acceleration ramping.

I'm still looking into dynamic motion profiling, but I haven't figured it out yet.
Gear slower. It will do wonders here.

Tom Bottiglieri 02-03-2015 18:19
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Jared (Post 1452386)
I have two ideas that might help
If you want to stick with plain PID, you could try just increasing the value of kD. If it starts to oscillate a lot, try a low pass filter (moving average over 0.1 seconds or so) on the sensor value. This will help slow the elevator, but it may not be enough.
.
Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.

virtuald 02-03-2015 18:30
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1452398)
Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.
More off topic -- I'm pretty sure that the JVM just does a sleep under the hood. To get more precise timing in python, we did a big sleep, then sleeps in increments of 200us to get the rest of the way there. We get +/- 0.5ms accuracy with this method.

Jared 02-03-2015 19:26
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1452398)
Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.
Yes. Again and again, we run into weird timing issues with the roboRIO. The cRIO's timing jitter couldn't be measured with a millisecond timer, but the roboRIO's can be. The roboRIO occasionally gets suddenly very bad at timing for 10 or so seconds. I battled lots of weird intermittent timing bugs with the roboRIO when trying to get our autonomous down - we're driving, lifting, swatting, intaking all at the same time.

Our elevator control originally used PD control, but we had intermittent issues with oscillation.

Our PID controller is here: https://github.com/dicarlo236/2015-R...robot/PID.java
Our Updater that deals with PID is here: https://github.com/dicarlo236/2015-R...t/Updater.java

I assumed that I messed up something in my PID class for the derivative calculation, so I took it out, and we're only running P control now. However, we still experienced overshoot of 4" or more about 1 in 100 times. I've only had the bug happen once when I was analyzing loop timing, and it was caused by TimerTask waiting too long to call the run() method, and the P controller couldn't run and update the motor value. I was originally running all control loops (elevator PID, drive followers) in the same thread, and I split it up into separate threads for elevator and drive, but it did not solve the problem.


I have two videos from our competition that show the problem. In the first video, you can see that the robot drives smoothly and accurately in autonomous mode, and the elevator moves properly throughout the whole match. If you watch our robot load from the feeder station or place totes, you'll see that the elevator is tuned well to work well under any load. Randomly, this exact elevator code will have tiny issues/jerky movement, then go back to normal.

https://www.youtube.com/watch?v=7vw2...ature=youtu.be

In the second train wreck of an autonomous mode, our robot doesn't drive smoothly at the beginning, the swatter swats too early, the intake turns on too late, the turn begins too early, the drop happens too late, and the drive stops too late. In teleop, the elevator control has an issue and doesn't drop low enough. At that point, I switched to manual control.

https://www.youtube.com/watch?v=2pr8...ature=youtu.be

The second video was likely taken during our second finals match (the problem happened twice). The identical autonomous program ran in the first and third finals match, and worked correctly both times. This behavior was very close to costing us the event, and I'd really like to get a good idea of what's happening.

I am not 100% sure what caused the issues, but here is my current thought as to what went on.

The first time it happened, it was triggered by an e-stop of the field. The match was started while the announcer was in the middle of announcing the first alliance, and the field people e-stopped the robot. I went out, reset the robot, but when I got back to the driver station, the robot was in autonomous disabled, not teleop disabled like it normally is when it is first FMS connected. For some weird reason, this caused the FMS not to communicate the remaining match time to the robot. I detect whether the robot is connected to the FMS by checking to see if the time remaining returns a reasonable number, which decides if we should run the match version of autonomous mode vs. the practice mode. The two versions are exactly identical, except that the practice mode fails to run System.gc() at the beginning because I accidently commented out the wrong line in queue.

The second time it happened, I messed up a few changes when we dialed in our drop/back up for the carpet at the event, which was a little different from the old carpet back home. I removed only the line system.gc().

We don't have any mentors on our team who are familiar with Java or are programmers, so I've been unable to really figure out why System.gc() helps with loop timing.

There's also an issue of the roboRIO's internal clock. On powerup, it thinks it's 1970. If you start your timer task then, then connect to the driver station, which syncs the roboRIO's date/time, it thinks it has to make up for 45 years of not running your code, which causes other issues. Both times when our auto failed, this was NOT the problem, as the elevator won't run if this case happens, and the elevator ran both times.

Spoam 02-03-2015 19:28
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by AdamHeard (Post 1452390)
Gear slower. It will do wonders here.
+1 for this. As a team that also uses PID for elevator control (although we mostly use it to minimize the torsional stress caused by our braking mechanism) the first thing we did to get a manageable speed was lower our gearing by a lot. That has the added benefit of providing some resistance against gravity. Worked great, as Adam suggests. It sounds like right now you are unnecessarily fast and you'll get the most out of your motors if you gear slower.

Quote:
Originally Posted by Tom Bottiglieri (Post 1452398)
Off topic a bit - I saw your team was using Java this year. Have you run into issues with the timing of the JVM's Timer? We have used this construct successfully over the past two years, but on the roborio the timing is complete garbage. We have ditched using derivatives on any control loops due to massive noise.

My best theory is the squawkVM was ported manually and used VXworks timers under the hood. The standard JRE we use now probably just sleeps or something.
Hmm, I'm curious about this. We also use java, but all our mechanisms are currently running PI control. Thank you for pointing this out.

Tom Bottiglieri 02-03-2015 19:34
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Jared (Post 1452430)
We don't have any mentors on our team who are familiar with Java or are programmers, so I've been unable to really figure out why System.gc() helps with loop timing.
1) Any object allocations (using the 'new' operator) cannot be assumed to be constant time, as it is basically just mallocing. System.gc is probably just clearing out a portion of memory large enough to not cause the memory allocator to have to look very far to find a spot. We allocate very infrequently and never in control loops to help with this issue.
2) The garbage collector probably won't need to run much within 15 seconds after you explicitly call it. This could be eating CPU.

The real answer is probably to use C/C++.

:-/

Jared 02-03-2015 19:37
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1452434)
1) Any object allocations (using the 'new' operator) cannot be assumed to be constant time, as it is basically just mallocing. System.gc is probably just clearing out a portion of memory large enough to not cause the memory allocator to have to look very far to find a spot. We allocate very infrequently and never in control loops to help with this issue.
2) The garbage collector probably won't need to run much within 15 seconds after you explicitly call it. This could be eating CPU.
I do not believe we are allocating anything in our control loops. All our variables are declared and our objects instantiated outside of the loops to avoid memory leaks.

Our CPU usage is around 50% during normal use and 60-65% during auto.

It may just be a coincidence that System.gc() didn't run when we had issues.

Merfoo 02-03-2015 21:18
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Jared (Post 1452430)
Our PID controller is here: https://github.com/dicarlo236/2015-R...robot/PID.java
Our Updater that deals with PID is here: https://github.com/dicarlo236/2015-R...t/Updater.java

I assumed that I messed up something in my PID class for the derivative calculation, so I took it out, and we're only running P control now.
I believe the mistake you made for the derivative calculation is that you never update the variable lastError in your update function. You also don't appear to initialize the variables i and lastError so if you try to run this code you'll get variable uninitialized errors, but I think you fixed this at competition and just didn't push that code to github else I don't see how this could work.

Code:
@Override
        public void update() {
                // PID calculations
                double dt = .02; // length of time between each calculation
                // calculate how far from our target we are
                double error = setPoint - source.pidGet();
                // p is proportional to error and our kP gain
                double p = error;
                // integrate error
                i += error * dt;
                // make sure it isn't too big
                coerce(i, -max_I, max_I);
                // differentiate error
                double dError_dt = (error - lastError) / dt;
                double d = dError_dt;
                //output is sum of all terms multiplied by gains
                double result = kP * p + kI * i + kD * d;

                // check to see if we're at our target
                if ((Math.abs(dError_dt) < max_derror_dt)
                                && (Math.abs(error) < max_error)) {
                        // reset I if we want to
                        //possibly add decay?
                        i = (reset_I_whenOnTarget) ? 0 : i;
                }
               
                //set output
                if(enabled){
                        output.pidWrite(result);
                }
               
               
               
        }

Ether 02-03-2015 21:30
Re: Elevator Motion Profiling / PID Ramping
 
2 Attachment(s)
Quote:
Originally Posted by Aero (Post 1452358)
our elevator is really fast. It's about 0.75 seconds from bottom to top.
First, take Adam's advice about gearing (post#13). Then...

Quote:
Originally Posted by Aero (Post 1452378)
motion profiling really is what we want. How inefficient would it be to generate a new motion profile every time we change setpoints?
Well it depends on your definition of inefficient I guess.

If you need to change the setpoint only when the speed is zero, it's pretty straightforward to generate a sinusoidal profile for smooth acceleration and deceleration.

Given the max desired acceleration M and the distance D to the new position, compute the constants T, K1, K2, and K3 as shown in the equations. Then you can use the functions a(t), v(t), and x(t) to generate a nice smooth trajectory to the new target. "t" is elapsed time from start of profile.

Note that T will be the time-to-destination and K2 will be the maximum speed.

See the example profile for M=3.5 ft/s2 and D=5 ft.

Gdeaver 03-03-2015 08:34
Re: Elevator Motion Profiling / PID Ramping
 
I haven't seen much discussion about this on CD but, There is a fuzy logic controller in labview. If implemented well can solve control problems very well. However, This is not a good time to try this path. Off season project.

Jared 03-03-2015 20:21
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1452434)
The real answer is probably to use C/C++.

:-/
Switching would likely fix the problem, but it's not a good solution.

The motion code I had is copy pasted from a project that ran perfectly on the cRIO - except I used Vectors instead of ArrayLists. There were no timing issues ever.

It's ironic that the fancy dual-core ARM controller running realtime linux and a newer version of Java has less accurate timing than a very outdated version of Java running on a system an order of magnitude less powerful.

Tom Bottiglieri 03-03-2015 23:06
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Jared (Post 1453066)
Switching would likely fix the problem, but it's not a good solution.

The motion code I had is copy pasted from a project that ran perfectly on the cRIO - except I used Vectors instead of ArrayLists. There were no timing issues ever.

It's ironic that the fancy dual-core ARM controller running realtime linux and a newer version of Java has less accurate timing than a very outdated version of Java running on a system an order of magnitude less powerful.
The robot code does not run as a real time process. Nor does the standard JRE have real time support.

(That being said, I don't think C/C++ programs run as real time processes by default either.)

virtuald 03-03-2015 23:07
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1453146)
The robot code does not run as a real time process.
That's a good point. Wonder why not?

MrRoboSteve 04-03-2015 11:58
Re: Elevator Motion Profiling / PID Ramping
 
The JVM has changed a lot since the 1.3 version that was used on the cRIO.

Do we know what the startup command line looks like for the Java VM? I am curious to see if there are special settings regarding garbage collection.

You want to do GC tuning using the command line parameters, not by calling System.GC(). System.GC() can be undesirable as it can trigger a full GC when you shouldn't need one. http://stackoverflow.com/questions/6...gc-do-anything has some discussion.

This article discusses the tradeoffs in GC tuning. If I was having issues like this, I'd want to be looking at the output of -verbose:gc to see if I had big pauses. Then I'd experiment with the parallel collector, using in particular -XX:MaxGCPauseMillis to set a cap to the amount of time spent in GC. You want lots of very short GC runs in the younger generations.

I'd also set -Xmx and -Xms to the same value, large enough that -verbose:gc never shows a full GC occurring during a run. If you're getting full GC runs occurring, you probably need to look at changes in your program to reduce allocation as there's too much memory pressure.

chloe 05-03-2015 00:00
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Jared (Post 1452430)
Randomly, this exact elevator code will have tiny issues/jerky movement, then go back to normal.
Usually jerky movement is a sign that your dampening / D factor is too high. Are you maybe having a brownout that causes your elevator motors to stop briefly?

Also you could try using your PID to control velocity rather than position.

Tom Bottiglieri 05-03-2015 00:41
Re: Elevator Motion Profiling / PID Ramping
 
We have alleviated some of the issues with timing by measuring dt for every iteration of the control loop. This still isn't good enough to use any derivative in the controller, but it makes the motion a bit smoother. (You will probably over/undershoot the expected position part of your profile and get a bunch of error out of nowhere, causing the jerky motion.

Tom Bottiglieri 11-03-2015 12:48
Re: Elevator Motion Profiling / PID Ramping
 
A bit of a follow up:

I talked this weekend at CVR with Joe Hershberger, who develops the RoboRIO side of the FRC stack. There is a construct in the HAL called a Notifier which uses the FPGA to generate interrupts at specific period. The CPP version of WPILib has support for this, but the java version is missing a JNI wrapper for this. Currently all timing based stuff (including the bundled PIDController) is being doing using Thread.sleep.

So, it seems possible to get decent timing in Java, but someone is going to have to get the Notifier built into the JNI and working. Has anyone managed to get the allwpilib repo java stuff built? The documentation isn't incredibly helpful.

rrossbach 11-03-2015 16:27
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Tom Bottiglieri (Post 1456485)
So, it seems possible to get decent timing in Java, but someone is going to have to get the Notifier built into the JNI and working. Has anyone managed to get the allwpilib repo java stuff built? The documentation isn't incredibly helpful.
I was able to successfully build on Ubuntu back in January when I had to add some missing JNI bindings for the DIO's which were needed to get ultrasonic sensors working in wpilibj.

Taking a quick glance through the source, it looks like Java already has the FPGA interrupt infrastructure available so hopefully adding support for Notifier to wpilibj isn't too bad....should require adding 1) a NotifierJNI class provide the HAL bridge; and 2) a Notifier class for robot programs to use. I'll see if I can poke around with this over the weekend.

- Ron
Team #2607 controls mentor

mmaunu 04-08-2015 23:03
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by MrRoboSteve (Post 1453337)
The JVM has changed a lot since the 1.3 version that was used on the cRIO.

Do we know what the startup command line looks like for the Java VM? I am curious to see if there are special settings regarding garbage collection.

You want to do GC tuning using the command line parameters, not by calling System.GC(). System.GC() can be undesirable as it can trigger a full GC when you shouldn't need one. http://stackoverflow.com/questions/6...gc-do-anything has some discussion.

This article discusses the tradeoffs in GC tuning. If I was having issues like this, I'd want to be looking at the output of -verbose:gc to see if I had big pauses. Then I'd experiment with the parallel collector, using in particular -XX:MaxGCPauseMillis to set a cap to the amount of time spent in GC. You want lots of very short GC runs in the younger generations.

I'd also set -Xmx and -Xms to the same value, large enough that -verbose:gc never shows a full GC occurring during a run. If you're getting full GC runs occurring, you probably need to look at changes in your program to reduce allocation as there's too much memory pressure.
I realize that this conversation is a bit dormant, but I do have a question about command line parameters. Can we modify the command that runs our robot code by adding parameters like the ones you mention here? I see where to do that (I don't have a roboRIO handy, but I believe that the command is stored in the file /home/lvusr/robotCommand) but want to know if it is "competition legal". I don't see any specific reason that it wouldn't be legal and I really hope that it is.

BenGuy 04-08-2015 23:36
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Aero (Post 1452347)
Our elevator is way too fast.

We're currently using a standard PID loop, but it accelerates ridiculously quickly and throws totes.

I've looked into motion profiling, but can't see an easy way to (quickly) dynamically generate profiles between two arbitrary points on our elevator.

Is motion profiling the best solution here, or is there a simpler way to stop our elevator from accelerating too fast?
I have another stratagy... Our team had the same problem when we used straight PID, that it was way too fast. We solved it with about 30 seconds of coding though. (I'm not the team programmer but do know a good amount about it so this is my best pseudo code impression): If error (in PID) > .35 then set speed to .35 This worked out great and we have used it since. Before trying to go with motion profiling, I would try this. It caps the max speed to .35, when the error finally gets below that, it decelerates like normal.

AdamHeard 04-08-2015 23:53
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by BenGuy (Post 1492411)
I have another stratagy... Our team had the same problem when we used straight PID, that it was way too fast. We solved it with about 30 seconds of coding though. (I'm not the team programmer but do know a good amount about it so this is my best pseudo code impression): If error (in PID) > .35 then set speed to .35 This worked out great and we have used it since. Before trying to go with motion profiling, I would try this. It caps the max speed to .35, when the error finally gets below that, it decelerates like normal.
If you have to cap the speed to keep it stable within your tuning skill set, you will see better performance if you gear down more. You'll end up with a more stable system that has far more margin for loading changes.

RonnieS 06-08-2015 00:13
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by AdamHeard (Post 1452390)
Gear slower. It will do wonders here.
+1

-Ronnie

Hugh Meyer 10-08-2015 12:04
Re: Elevator Motion Profiling / PID Ramping
 
1 Attachment(s)
Quote:
Originally Posted by Ether (Post 1452496)

If you need to change the setpoint only when the speed is zero, it's pretty straightforward to generate a sinusoidal profile for smooth acceleration and deceleration.

Given the max desired acceleration M and the distance D to the new position, compute the constants T, K1, K2, and K3 as shown in the equations. Then you can use the functions a(t), v(t), and x(t) to generate a nice smooth trajectory to the new target. "t" is elapsed time from start of profile.

Note that T will be the time-to-destination and K2 will be the maximum speed.

See the example profile for M=3.5 ft/s2 and D=5 ft.
Ether,

I created a spreadsheet to see if I could duplicate your example. Everything matches except for your statement "K2 will be max speed". My spreadsheet shows the max speed as 3.33 (cell I17) with a K2 value of 1.66 (cell D8). What am I doing wrong? Attached is my example sheet.

-Hugh

Ether 10-08-2015 12:33
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by Hugh Meyer (Post 1492995)
Ether,

I created a spreadsheet to see if I could duplicate your example. Everything matches except for your statement "K2 will be max speed". My spreadsheet shows the max speed as 3.33 (cell I17) with a K2 value of 1.66 (cell D8). What am I doing wrong? Attached is my example sheet.

-Hugh
The error is mine, not yours. The maximum speed will be 2*K2.

Thanks for pointing that out.

.

BenGuy 15-08-2015 10:05
Re: Elevator Motion Profiling / PID Ramping
 
Quote:
Originally Posted by AdamHeard (Post 1492412)
If you have to cap the speed to keep it stable within your tuning skill set, you will see better performance if you gear down more. You'll end up with a more stable system that has far more margin for loading changes.
I agree, but if you couldn't change this (if it was a pre-built system and couldn't be changed for some reason) this is my best offer of a way to fix the problem just in programming - it worked great for us this year.


All times are GMT -5. The time now is 10:56.

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