(I may have asked this here before. If so sorry for the rerun- getting a bit desperate )
Has anyone here worked with motion control (and/or is less math impaired than me - which is probably everyone...)
I have a 6' x 6' drawing machine in progress (basically a big 2 axis plotter). The rig is all constructed and the drive system is done (4 24v DC motors with optical encoders controlled through the Arduino (or Wiring) board). I've got parts of the programming done but I got stalled trying to write a trapezoidal velocity routine to enable smooth movement.
I've googled to little result. A description/explanation of what I am trying to do is here: http://tinyurl.com/28qm9w
I am probably over-complicating this but the sight of certain sorts of equations just elicit my deer-in-the-headlights response.
Looking at your problem from another angle, do you really need this calculation? If you have sensors for the actual x and y position then could your servo mechanism provide the smoothness you want through a relatively simple feedback mechanism. In essence your software does the integration by continuously sampling the position and comparing it to the previous position. The velocity and acceleration are easy to calculate and you could use a simple lookup table if you want different constraints on these when you are starting and stopping movement.
I am probably missing something so please let me know what that is, I clearly have no experience in this area
I may be over-complicating it (common trap to fall into) but I do think I need some sort of motion control- both to prevent jerking at the start/stop, and to prevent over-shooting the target position. It's a common issue- so I have been surprised to not find more (and mo' basic) example code out there.
I tinkered with some cubic easing algorithms and that seemed promising for a while (simpler maths) but there were some issues. Also wanted to try to implement this as a non-hack but I am way out of my depth. Guess I will go back to the cubic easing stuff and just try to get it sorta/kinda working.
I am curious to know what it is that makes you think you need to do any more than ensure that you maintain an upper limit on acceleration and deceleration? Assuming you are not overly concerned with movement efficiency. Is it worth complicating the implementation to get what may be just a small decrease in drawing time.
I must admit I know little about your application, except that I recognize in myself a desire for the best solution which, if I don't simplify, I often regret ;).
Hi~
The rig is fairly large (6 feet x 6 feet) and can scale to 20 feet x 20 feet. I could cap the max speed to avoid a lot of issues but the drawing speed would be unacceptably low. I did an earlier version of this with stepper motors and a commercial motor driver board that had the motion control stuff in firmware. Worked well except the steppers were painfully slow (had to gear them down to get decent torque) so I switched to DC gearhead motors- nice and fast.
Part of the idea is in the real time responsiveness of the drawing machine (user controlled, etc).
I hear ya though about "the best solution" - I fall into that far too often... as the old quote goes... "Damn it Jim, I'm an artist, not an engineer". Sound of wheels spinning...
I am controlling the speed through PWM (range 0-255) and to get the motor moving I need @ 80 to get enough torque.
so ....
minSpeed = 50
maxSpeed = 255
rampRate (amt to accelerate) is some fraction of the total. If the rampRate is 1 (for simplicity) then it will take 205 cycles (steps) to get to full speed (e.g. currentSpeed += rampRate). But what defines a cycle or step? If I am calling this in loop() it will ramp up too quickly. Most of the algorithms I have seen include a time factor but I don't have a time factor- the move will take as long as it takes.
Though I did see something @ time = travelDistance / velocity. Ok - I get that (200 mi / 50 mph = 4 hrs). I guess I can define an arbitrary time slice (e.g 200 ms) between increasing acceleration and just tweak until it seems ok.
And this link Home-Brew Shaft Encoders has some ideas on home made shaft encoders, the output of which if sampled at regular intervals could give you your time slices.
yeah- controlling to axes so they arrive at the same point at the same time would be nice...
About the rampUp/rampDown functions/states- it's more a question of when to call them- so if a move of 1000 encoder units is specified, the motor is accelerated over the first 25% (250 units),then cruises for 50% and then begins to ramp down after 75% (750 units).
The thing with a fixed delay: the motor velocity is changing in the ramp up/down states so the distance traveled in each time slice will not be the same so the acceleration/deceleration will be uneven/choppy.
Will keep tinkering though and maybe come up with some workable hack.
And this link Home-Brew Shaft Encoders has some ideas on home made shaft encoders, the output of which if sampled at regular intervals could give you your time slices.
Thanks - yeah, I saw that. Ironically that is the board I found that has builtin motion control. I guess he productized it. Alas... he doesn't release the firmware code (not that he should or anything) which is all I really need. http://www.gamatronix.com/
)
