Timeline for How to: implementation problem with Position control on a 3 Wheels robot (2 motorized) with velocity profile of trapezoid
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 20, 2022 at 17:00 | comment | added | maneedos | oups..my bad! of course torque is proportional acceleration. My mistake. Thanks for all the help. Although I am still confused about why achieving better results in terms of accuracy of the positioning is going to happen from velocity control+feed forwrad than in a scheme where position+feed forward control is implemented. As you said most probably I will have to try it. What about the overcome of the PWM threshold value in order to make the robot move, though. Is all I can do better tuning? Or do I miss something? Thanks again for your valuable replies! | |
| Dec 17, 2022 at 5:23 | comment | added | Chuck♦ | @maneedos - angular speed is not proportional to torque, angular acceleration is, same way force is proportional to acceleration for linear systems. Moment of inertia or mass are the constants of proportionality. You can use velocity or position control, but I think velocity control gives better performance. Try both! See what you prefer :) And yes, you got the u+ff correct. You'll always have to tune a PID controller, but feed forward is proactive and makes up the bulk response, leaving PID primarily for disturbances, which should be more consistent across a range of speeds. Best of luck! | |
| Dec 16, 2022 at 16:34 | comment | added | maneedos | Regarding feed-forward controller. I didn't understand why you said it doesn't use feedback. But I understood that you suggested to set the PWM value as: PWM=u+ff_pwm. Where u is the output of the classic pid (with velocity as input) -in order to handle the disturbances as you described them - and ff_pwm is the estimation based on the PWM-speed curve. Did i get it right? Seems nice approach, but again the gain must be carefully tuned otherwise the u value can ruin everything. Thanks again! | |
| Dec 16, 2022 at 16:30 | comment | added | maneedos | Thanks again @Chuck. Forgive my ignorance and persistence. Just trying to learn. Well, angular speed is proportional to torque. And torque is proportional to current. Then shouldn't it be similar? Moreover, based on the fact that my main concern is about achieving accuracy in reaching position, what is the trade-off (if there is one) if I switch to velocity control? Thanks in advance! | |
| Dec 15, 2022 at 20:04 | comment | added | Chuck♦ | The feed-forward controller is one that doesn't use feedback, so yes you'd plot steady-state speed at 10% duty cycle, 20%, etc. Then, when you get a speed reference input to go 3 meters per second, you go to your duty cycle/speed data, interpolate the duty cycle to get 3 meters per second, and send that PWM value and the output of the PID controller. The feed-forward control gets immediate response in the ballpark-correct value, and that leaves the PID controller to make up for disturbances. This will give you much better response over a wider range of speeds than PID control alone. | |
| Dec 15, 2022 at 20:01 | comment | added | Chuck♦ | @maneedos - As concisely as I can put it: PWM modulates current to the motor - it regulates torque, not speed. Any control scheme built around PWM as an input will fail to deliver what you want because PWM doesn't mean speed. The only exception would be if you had an electronic speed controller (ESC), but then that's what I'm proposing here - build a speed controller and pass your inputs to that. The total control signal would be the sum of the PID speed controller and the feed-forward speed controller. | |
| Dec 15, 2022 at 16:26 | comment | added | maneedos | Generally speaking, shall I expect that this scheme of control is going to be effective or not? I mean is this some approach other engineers follow? Lastly, I would like to ask if you agree with the following: It seems to me that it is not a good practice to avoid making this PWM-speed curve and trying to "fix" everything with the tuning of the gains. Thanks in advance - I truly appreciate your feedback - and sorry for the trouble. | |
| Dec 15, 2022 at 16:25 | comment | added | maneedos | Regarding the feed forward control: If you can shed a little bit more light here, I would appreciate it. The idea is that i must have a plot of PWM-speed curve which will feed the feed-forward control (as well as in the classic PID control). The classic PID remains the same and in its output I add (or multiply?) estimation of the PWM? This estimation is based on what? Also, can this be utilized in position control as well? Certainly, I need to study more feed-forward control, but any simple explanation is appreciated. | |
| Dec 15, 2022 at 16:25 | comment | added | maneedos | Regarding PWM issues: The ignition of the movement still troubles me. Maybe you have some comment about it? As said in the original post, this issue is normal - and should be expected - but in the practical world, it gives me trouble. Maybe I need more testing with the robot and then come back. Right now all I am doing to overcome this is to map (with interpolation) the control output result into some value with specific limits. Shall I try something different? | |
| Dec 15, 2022 at 16:24 | comment | added | maneedos | From your answer I understand that both in position and velocity control (that you described), the control output's unit - which I consider a problematic issue - is handled by the tuning of the gain (this is what i understand from what you refer to as scaling). Alright, this seems fair but that also makes tuning a little bit difficult in my opinion. | |
| Dec 15, 2022 at 16:23 | comment | added | maneedos | Thanks for your reply. Regarding the des_pos: The code expects the user to feed the robot with some des_pos which the robot shall travel. Based on this, I pass traj.generator parameters in order to achieve this. When the velocity profile is integrated, a s-curve type profile is created, which is the position over time. The position after t_final - that is the total time to elapse for the speed to become again 0 - must have reached the desired position. Since my goal is that the robot reaches the desired position, it feels to me better to feed the pid with position and not velocity. | |
| Dec 14, 2022 at 22:14 | history | answered | Chuck♦ | CC BY-SA 4.0 |