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.

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?

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.

Originally Posted by AdamHeard (Post 1452390)

Gear slower. It will do wonders here.

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, K₁, K₂, and K₃ 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 K₂ will be the maximum speed.

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

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

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.