|
Post by hexpod on Oct 19, 2016 15:16:05 GMT
Trying to solve another problem in the plugin. When fast cues occurs we are getting an erroneous trajectory.
The motors with the smaller distance to accomplish a DoF like pitch or roll, goes to their position to fast. In order to correct this, I would need a simple tecnical information about how the controller is dealing with the motor speed.
Is the gap between the cue and the sensor position responsible for the speed? Bigger the gap faster the speed?
Thanks
cheers
|
|
|
Post by tronicgr on Oct 19, 2016 17:47:15 GMT
Trying to solve another problem in the plugin. When fast cues occurs we are getting an erroneous trajectory.
The motors with the smaller distance to accomplish a DoF like pitch or roll, goes to their position to fast. In order to correct this, I would need a simple tecnical information about how the controller is dealing with the motor speed.
Is the gap between the cue and the sensor position responsible for the speed? Bigger the gap faster the speed?
Thanks
cheers
Exactly, the bigger the gap the bigger the speed, thus is set by the PID and max motor speed values. So if the target cue is very close to the current position, the motor may not even move if the voltage threshold is low. But then you could always use the Min motor speed setting to start the motor in such conditions. The trade off is that you may get some extra vibrations near target position. Thanks Thanos
|
|
|
Post by hexpod on Oct 19, 2016 19:02:54 GMT
"Exactly, the bigger the gap the bigger the speed, thus is set by the PID and max motor speed values."
Yes. Lets's develop a bit...
When the cue speed is slower or equal than the max-servo-speed, the trajectory is correct but what happen when the cue is faster than the servo-max-speed??
For ex. in a roll DoF, motor 1 and 2 have a much smaler distance to accomplish than motor 4 and 5 and in case of very fast cues, (faster than servo-max-speed) they (1and2) are reaching their position before the others. - erroneous trajectory.
cheers
|
|
|
Post by tronicgr on Oct 20, 2016 12:32:55 GMT
So what you ask is a variable max motor speed, based on the motion cues trajectories... hmm
Let me see, it would require math to be able to set it right, and the controller does not know all the limits that are done on software...
Perhaps the best solution to it would be for the 6dof plugin to be able to read the actual position of the motors and set the max motor speed for individual axis on the fly.
It can be done, you know, from controller side, Fabian is already using these resources for his pid calibration utility and bff bridge software...
Thanks Thanos
|
|
|
Post by hexpod on Oct 20, 2016 12:36:20 GMT
When the cue speed is slower or equal than the max-servo-speed, the trajectory is correct but what happen when the cue is faster than the servo-max-speed??
For ex. in a roll DoF, motor 1 and 2 have a much smaler distance to accomplish than motor 4 and 5 and in case of very fast cues, (faster than servo-max-speed) they (1and2) are reaching their position before the others. - erroneous trajectory.
cheers
That's the case ONLY in the small scale platforms (without sensors). sorry for misleading.
In the full scale (with sensors) the trajectory is more or less correct. However I have the feeling that it could be improved.
Let me explain my idea:
For now, all six arms are reaching their destination using proportional speed to the sensor gap. That's fine, but the controller in case of fast cues is receiving the information ONLY about the final position of the arms and will send them with a proportional speed that every of them reach the destination simultaneously.
That's not very kinematic way to proceed.
My idea is to link the hardware and the software plugin in a way that regardless the speed of the cues arriving to the controller, the platform will stick the kinematic path to accomplish the movement.
Maybe it could be achieved by matching the rotation variable speed to the max speed of the servos. In that case the slower arms could follow the destination NOT with a proportional speed but following the kinematic trajectory.
Sorry about my chaotic explanation.
Does it make sense to you??
cheers
|
|
|
Post by hexpod on Oct 20, 2016 14:39:42 GMT
"Perhaps the best solution to it would be for the 6dof plugin to be able to read the actual position of the motors and set the max motor speed for individual axis on the fly."
So basically, my simple idea would be to put a settable max-speed-limit on the "beta[6]" variable (in radians per second or RPM) to match the max speed of the motors in the system.
If my hypothesis is correct, it should act like a speed filter between the telemetry and the controller, making synced with the 3d model, every displacement of the platform .
Do you have a better idea?
cheers
|
|
|
Post by tronicgr on Oct 20, 2016 17:42:04 GMT
When the cue speed is slower or equal than the max-servo-speed, the trajectory is correct but what happen when the cue is faster than the servo-max-speed??
For ex. in a roll DoF, motor 1 and 2 have a much smaler distance to accomplish than motor 4 and 5 and in case of very fast cues, (faster than servo-max-speed) they (1and2) are reaching their position before the others. - erroneous trajectory.
cheers
That's the case ONLY in the small scale platforms (without sensors). sorry for misleading.
In the full scale (with sensors) the trajectory is more or less correct. However I have the feeling that it could be improved.
Let me explain my idea:
For now, all six arms are reaching their destination using proportional speed to the sensor gap. That's fine, but the controller in case of fast cues is receiving the information ONLY about the final position of the arms and will send them with a proportional speed that every of them reach the destination simultaneously.
That's not very kinematic way to proceed.
My idea is to link the hardware and the software plugin in a way that regardless the speed of the cues arriving to the controller, the platform will stick the kinematic path to accomplish the movement.
Maybe it could be achieved by matching the rotation variable speed to the max speed of the servos. In that case the slower arms could follow the destination NOT with a proportional speed but following the kinematic trajectory.
Sorry about my chaotic explanation.
Does it make sense to you??
cheers
OK, the mini RC servos do NOT use PID values or Speed setting from the amc1280usb. Just thenter target position, to which theyou go as fast is possible. However, I have developed a slow speed for them, which I apply when they return in home position, using the step parameter in that menu. The mini servo model is not designed for accurate motion trajectory, rather for estimate of the motion range. Using small DC gearmotors with actual potentiometers with the 1A DC motor driver shield I sent you, will give more accurate trajectory profile in the motion very much slower to the full size platform. Thanks Thanos
|
|
|
Post by hexpod on Nov 5, 2016 14:21:50 GMT
Using small DC gearmotors with actual potentiometers with the 1A DC motor driver shield I sent you, will give more accurate trajectory profile in the motion very much slower to the full size platform.
what is the jumper config for that mode?
Thanks
|
|
|
Post by tronicgr on Nov 6, 2016 15:30:44 GMT
Using small DC gearmotors with actual potentiometers with the 1A DC motor driver shield I sent you, will give more accurate trajectory profile in the motion very much slower to the full size platform.
what is the jumper config for that mode?
Thanks
The small 1A DC motor driver uses the same PWM mode as the clearpath motors. There is a jumper near the drivers side that can be removed to use external power supply. I'll show you where tomorrow when I have access to my equipment. Thanks Thanos
|
|