Balancer robot slams to full speed when I start it

[sgordon777]

Hello,

I’m trying to build the balancer robot from the videos. I have different motor, encoder, and driver
-MOTORS: GM5208-12 (7PP, 22K)
-SENSORS: MT6701 magnetic sensor.
-DRIVERS: DRV8313
-CONTROLLER: NUCLEO32-G431KB
-I am not using a Bluetooth module (I have hard-coded the throttle and steering to zero)

All equipment (motors, drivers, encoders, controller, IMU) works fine indivdually and in other FOC projects I do

I’ve set up polarities just like the video:
-Positive torqe command to FOC moves vehicle forward
-movement in the positive direction results in positive shaft velocity on motors
-IMU initializes fine, and gives a negative value when I tilt the vehicle forward

I’m using the exact code from the GitHub, with changes for my equipment, and no Bluetooth controller(throttle and steering are set to 0)

But when I trun on the power and the IMU calibrates, the velocity slams to full-positive. It looks to me as though one or both PID loops are going into positive feedback. I don’t understand the control strategy here so I’ve not been able to troubleshoot effecitvely, but have tried playing with tunings to no avail.
Are there some intermediate states, or some other troubleshooting advice which could help me to get this working?

One thing I did try was forcing the “pitch” value returned from the IMU to zero. In this configuration, the system starts up, but the slightest movement slams the system to full velocity, as if in positive feedback. I feel like there’s a sign wrong somewhere (something needs to be negative)

Thanks,
Steve

[sgordon777]

Ok, I did two things I think it MIGHT be working right now, though not nearly as well as the vehicle in the video… What I did:

#1-Negated the shaft velocity (see code edit below). This solved the positive feedback issue I was seeing, and now the velocity converges to zero at zero tilt rather than taking off.

#2-Reduced the “D” (derivative) term in the stability PID. This dampened a large vibration which resulted after I fixed issue#1.

void loop() {
…
// read pitch from the IMU
float pitch = getPitchIMU();
// calculate the target angle for throttle control

// ORIGINAL
// float target_pitch = lpf_pitch_cmd(pid_vel(( motor1.shaft_velocity + motor2.shaft_velocity) / 2 - lpf_throttle(throttle)));

// UPDATED: NEGATE SHAFT VECLOCITY BELOW
//float target_pitch = lpf_pitch_cmd(pid_vel(( - motor1.shaft_velocity -motor2.shaft_velocity) / 2 - lpf_throttle(throttle)));

float voltage_control = pid_stb(target_pitch - pitch );
…

Now the system behaves pretty close to the one in the video, though it doesn’t perform AS well. I’d be happy for any tips on how to optimally tune the vehicle, or any mods to the geometry of the vehicle or other parameters/conditions in which the performance might improve.

[Antun_Skuric]

Nice!
Yeah, as your balancer is a lor lower you have a lower center of mass which makes the its dynamics muc faster.
You are on the right way and should probably retune the PID gains.
If it helps here is the proceudure I usually use for tuning the gains:

Self-Balancing robot

Hello @Marc_O, There are two approaches really. Either you build a model and do a proper control theory controller calculations. Or you tune it in by hand. If you do have a model you can calculate the LQR controller or optimal PID controllers and similar. Now if you do not have a model, there are two approaches that I’ve used: state space PID stabilisation + PID velocity cascade Ti tune them i find it really useful to establish a very simple communication protocol as motor commands. You ca…

[sgordon777]

Thanks Antun, I’ll follow up for tuning and I’ll likely make my COG higher…

I found that the balancing PID works flawlessly, IF I hard-code the output of the velocity PID controller (target_pitch) to zero. -This decouples shaft velocity from pitch, resulting in a well-balanced vehicle which doesn’t resist changes in shaft_velocity (ie it’s free to move around by pushing it)

So the problem is the velocity controller I think -It sometimes (it seems inconsistent) converges on a non-zero target_pitch value, resulting in a tilted vehicle which wants to move. If I rock the vehicle by hand I can usually get the target_pitch to be zero.

I wonder if the issues I’m seeing with the velocity controller have anything todo with me having to kludge it to negate the shaft velcity?

Steve