0
$\begingroup$

I am working on a hobby project for self balancing robot. My robot balances quiet well, so my next step is to start moving it. I saw in some blogs that they used a cascade control algorithm as shown belowenter image description here

So I have the following question which is giving me a hard time

  • When I see some videos about segway like systems (like boston dynamics here ), I see that before moving forward, the robot moves a bit backward (to generate a tilt) which I think is justified because it must first get an error to get started in the forward direction. So will this kind of control system be able to handle that or do I need to code it seperately?
|improve this question
$\endgroup$
1
$\begingroup$

If you for example want to move in the positive direction the speed error will become positive. The first PID controller will translate that into a (most likely) positive angle reference as well. So the inner PID controller will try to bring the measured angle to the positive reference, which initially only can be achieved by driving backwards. Once that positive angle is achieved the wheels will need to continuously drive forwards in order to exert a torque to keep the robot at that angle. So you do not need to do anything additionally to achieve this behavior.

|improve this answer
$\endgroup$
  • $\begingroup$ Hi Thanks for coming back. I was experimenting with my robot yesterday and I saw that indeed it does behave like that. i think the effect comes from the derivative term as also implemented in Arduino PID library. The PID output is computed as: Output = kp * error + ki * errSum - kd * dInput; So initially the derivative term is negetive and therefore the motor spins back. $\endgroup$ – Nischal Jan 11 at 12:24
  • $\begingroup$ @Nischal Normally there shouldn't be a negative sign in front of kd. Theoretically kd could be negative which would give the same behavior, but in practive you would never do this. If the system has enough friction then you could also set the kd term to zero, in which case the robot would still initially move backwards. This is also common behavior for non-minimum phase systems. $\endgroup$ – fibonatic Jan 11 at 12:59
  • $\begingroup$ yeah true, Kd is not negetive, but the negetive sign comes from the fact that dInput = ((Setpoint - Input2) - (Setpoint - Input1) ) / dt = -(Input2 - Input1)/dt. So in the algorithm, since the setpoint remains the same (or to eliminate from jerky behavior if it is changed), only the difference between the inputs is taken which gives a negetive sign. See here $\endgroup$ – Nischal Jan 11 at 13:06
  • $\begingroup$ @Nischal You are correct, I read it too quickly and mistook dInput as dError. But initially the derivative would be zero, since the robot is at rest in the vertical position. Initially the biggest contribution to the output will most likely be the kp*error term. The main reason why the robot initially goes backwards is probably due to the structure of the cascading control as described in my answer. Either way the two PID loops are able to generate the desired behavior, so there is no need to add additional control logic to achieve this. $\endgroup$ – fibonatic Jan 11 at 13:54
  • $\begingroup$ Hi Guys, I was thinking about the problem and I was wondering if the outer loop was actually needed? What if I just increase the Angle_Setpoint in steps to a constant value let's say 3 degress. I guess the outer PID will also do the same with its I term once the set_speed and measured speeds become equal? Is it a correct argument? $\endgroup$ – Nischal Feb 22 at 9:14
1
$\begingroup$

After much researching, I found an answer to my question. I think I asked the wrong question. The robot moves in opposite direction initially and then in correct direction because it is a non-minimum phase system meaning it has a pole in right half plane. These kind of systems initially move in opposite direction before moving in correct direction. This is clearly explained in this video at time = 7:46 minute.

|improve this answer
$\endgroup$
0
$\begingroup$

The fastest way in tuning the pid controller for a self-balancing is to put a remote control into the loop. That is a knob which adjusts pid parameters manual, similar to what musicians are using for fine tuning a bass-guitar. What exactly the knob modifies depends on the control system. It can be the sinus waveform, the amplitude or the delay until the feedback is send back into the system. The important thing is, that the knob can't be controlled by the pid system itself but the input is given from the outside. That's a well informed human operator who is able to detect if the balancing works or not.

The knob will transform a closed loop system into a semi-open system which depends on it's environment. The resulting problem “which position needs the knob?” is a sign for progress because it helps to reduce a complicated control problem to parameter finding.

|improve this answer
$\endgroup$

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.