I am currently working on a mecanum wheels robot, but I'm having some trouble implementing speed control.
Joystick would be used as input to move the robot in any direction in a 2d plane. Joystick input is a 2d vector, containing direction and angle. The motors will be controlled via PWM.
Ideally, i would like to reduce shock or acceleration/deceleration mutations when moving the robot. Through my google-fu, I have found that a sigmoid curve is better than linear acceleration. If the input is an instruction for the robot to go from location a to b, it'll be easy to implement. But I can't think of how to implement sigmoid curve with thousands of joysticks input per second affecting where the robot will move, with concern that each sigmoid curve generated from input will overlap each other, leading back to acceleration/deceleration mutations.
I am open to any suggestions for implementation and speed controlling curves that I am not aware of. Thank you in advance :)
What he is saying is that hardware and software are very different. A high speed game might take 100-200 inputs / second and that is a LOT. Half that is good enough for most games. 1000s per second is way, way off the mark, its nuts for software and hardware quite simply cannot handle that. Hardware can handle maybe 50/sec, if that. Its more likely 10-25 / sec.
sigmoid is just a fancy way of saying a step function. Its differentiable and sometimes that matters, but for the life of me, I don't see it here, so why not use a normal step function: if x < low out = value 1, else out = value 2. Its a lot easier to implement that, unless you are, again, doing calculus on the equation for some unholy reason.
Speed and turn are related. The faster you go, the more you typically want to throttle the turning. That is, at 100 MPH, you may only want to allow the vehicle to turn at 5-10% of its maximum turn capability. At 1 MPH, it would use 100% of it. These values are driven by the vehicle's physical dynamics.
You also may want deadbands… a place where little jitters in the joystick hardware don't do anything. These come in 3 flavors... a band around 'zero' or 'not touching it' position, one at the upper and lower, and possibly a third one that checks 'is the current output and the last one so close that any commands are likely bogus'. This just saves making many little moves on the motors that are wearing things out doing not much.
you also want DIO watchdogs... this is 'driver induced oscillations' which is fancy verbiage for 'the hardware can't keep up with the idiot driving' eg you yank full left, full right, full left and its still trying to reach the first full left and the pilot is so far ahead of the hardware he is making foolish commands and getting frustrated. This is most often seen in flying robots, where the vehicle responds rather slowly to commands (big slow aircraft for example) but the pilot is freaking out...
you can also do a lookup table for speed. Desired speed in, current robot status vector (may include environment, like rolling downhill or flying into the wind) tied to it, command to the motors out. It may have 4 or 5 dimensions and a lot of values, or you may interpolate a sparse table idea, etc.
After thinking for quite some time. I'm think of calculating it via vector. The movement of the robot will be determined by joystick vector input (as movement target), previous state output vector (to damp the movement of the vehicle), and an opposing vector (to slow robot to resting position). I think DIO would be reduced to a minimum in this case.
I'll definitely implement deadbands and step function for acceleration (Its a lot easier to just do step function).
I shouldn't say thousands of joysticks input per sec, but maybe around hundred mark.
well, check your motor. Most real motors etc simply can't respond that fast. If you have something expensive, sure, but the typical stuff, hundreds/sec is still a bit dicey. /shrug your specs on the device will tell you what it can handle. Its usually harmless to send stuff too fast, but you do much more loop/computation/etc than is needed, eating your cpu for nothing, and if its a small robot, it may not be hauling around a lot of cpu.
@salem c Yeap I'm planning to throttle the robot using an opposing vector force in proportional to current vector force. But for now I need to make a minimum viable product (although its a hobby project :P).
@jonnin I'll be sure to test the motor and driver extensively to prevent any unexpected behaviour. If hundreds of input proves too much, I could do it like game engine, taking hundreds of inputs per sec, but only refreshing screen 60hz (just an example, i know there's freesync and the like).