Our programmers played around with slew rate control last year in an attempt to prevent the jarring associated with initial robot movements and stopping. They were able to do it but it ended up driving the drivers nuts due to difficulty stopping precisely where they wanted. The slew rate programming would make the robot decelerate slowly, often moving after the driver had wanted the robot to stop. This makes sense since the drivers cant tell the robot they want to top until they want to stop, and if the robot wants to decelerate slowly, it has to keep moving.
I don't understand the code but my question is whether other teams have this problem. 
Thank you
Quote 0 0
If you post your code, other people would be able to duplicate your situation.
And it would make it easier for some team to answer.
And lots of practice can train the brain to work around many idiosyncratic control systems.
I suspect your slew rate is set too slow,  or you have a wait() in your code, which is quick and dirty way, but not good.
I've wondered about implementing "jog mode", that I have seen on IC wafer probers, that does repeated movements of small increments, which sounds good for doing precise alignment.
  Precise alignment to pick up something is a common task, but it can be made more difficult by robot design with a long arm reach away from the wheels.
In spite of that,  modeling future movements of the robot/vehicle is a critical part of self-driving AI, as well as human driving.   
The way you describe it " the drivers can't tell the robot they want to (s)top until they want to stop"
sounds like these drivers are not yet ready to drive a car.   'oh the light is red,  I should put on the brakes when I get there'
  But snark aside,  please post your code and I'll definitely look at it, and can probably explain it to you.
Quote 0 0
I will try to get the code and post it. They were able to adjust the slew rate control in the code to shorten the coast time (the time between letting the joystick return to 0 and the robot stopping) but still had trouble figuring out how far the coast was going to be. The coast varied based on how fast the robot was going at the time, which was affected by the analog (variable) joystick position at the time.
They did not practice a long time with this and your comment about learning to drive with this change is pertinent. I am guessing they could. 
I guess my question boils down to this. Do teams that employ slew rate control have to learn how to "coast" into position? Is there a trick?
Quote 0 0

Ideally for max performance, when you program the slew control you should be able to have different rates for when the signal to the motor is rising vs falling. This way you can customize your driving controls to be more reactive (or aggressive) when braking and slower when moving forward. Programming-wise this will involve keeping track of the previous command sent to the motor, and the switching between your slew rates depending on whether the current command is higher or lower than the previous one.

We previously discussed the Simulink block that makes all of this really easy to implement. You can always try out a simple controller in Simulink to prototype having different rising vs falling slew rates in your controls, and if your driver feels like it can be beneficial then you might want to go through the trouble of adding the extra wrapper in the code.  

Here is the explanation on how to do slew control in Simulink.


Hope this helps !


Quote 0 0