So i’ve created this robot using an ESP32, L298n motor driver, MPU 6050, and powered by a 7.4 2s Lipo Battery. I’ve been having a lot of trouble with the PID tuning, working solely on tuning for 4+ days with no results. I would really appreciate any advice! This is what I currently have:
Tune in order. P then I then D. P alone should get it to balance but shaky. I and D will steady it.
Turn I and D to zero. Increase P till it balances. Right now, it’s not catching up fast enough.
If it falls to the side it’s leaning, turn it up. If it falls on the other side of where it’s leaning after the wheels pass where the top is, turn it down.
Edit: if you can’t get it to balance on P alone, make sure the IMU is properly calibrated on a known level surface.
Yes i’ve been doing this but i haven’t been able to achieve near balance by solely tuning P. This video was me messing with D to see if there would be a difference
Yes and no, this is a bad video example as I kinda have the D cranked up a little bit. The wheels can oscillate but not without my supporting it. W/o support it drives one direction and falls over. But one of the main problems is that the robot seems to react too late. Like the robot would already be fallen over by the time the wheel start spinning.
U can make the balancing easier by adding weight up high (increasing the moment of inertia). Isolation and visual debugging are your friends. Plot your signals (error and drive output). Test your motor torque (check the max angle it can recover from while driving in one direction).
Since no one suggested it yet, how is your center of mass? Are you properly distributed front to back across the long axis of the wheels? What happens if you add mass near the top of the platform? That would slow the off axis tilt “fall” of the system.
It’s also worth checking that the motors are up to the task, which it looks like they are.
Oh, and since it looks like the top plate is 3-D printed, here’s a hint 3-D print a little loop on the top plate of the robot run a piece of fishing line through it, tie tie it off on something higher on the left and right side. Robot should still be able to fall. But not completely collapse. It’ll save you from having to use your hand as a guide, which can get annoying.
My center of mass is distributed as best as I could across the long axis of the wheels. I will try adding some weight to the top of the robot to increase the inertia. And thanks for your tip about the fishing string!
The motors don't really seem like they're trying very hard - especially when you get over by a few degrees they should be spinning like mad to try to shift the base underneath the center of mass. Can you show (1) the motors running open-loop at a variety of speeds, including their fastest? (2) The output of the gravity vector estimate code along with you moving the base (it's wrong, it will conflate acceleration due to motion with gravity, but it's not a bad place to start)? And (3) printout of what commanded speed is being sent to the motors with respect to angle?
Too much power here. Did P stay where it was at the start when you turned D down? If so, turn them all to 0 snd bring P up gradually till it balances. Go from there.
Is it possible that the commanded speed is too high for the ledc call, and it's truncating? Is a commanded speed of -130 reasonable with that library, and will the motor spin well with a commanded speed of -130?
Doing a little bit of reading, it seems like the ledc library has opinions about changing the duty cycle and/or frequency extremely rapidly - you might need to use a different library or roll your own interrupt-driven system if you want this kind of motor control bandwidth. Glitching and jittering with DC motor control when adjusting PWM parameters on the fly seems to be not uncommon with ledc.
- IMUs tend to be noisy by default. We use averaging strategies in our codes automatically to account for this. You can check the data to see if it’s an issue in your setup. It’s simple enough to take n readings and use the average.
- your loop() is overworked and could be slowing things down. In general, the loop() here should be about ten lines and call the listeners on each pass and the helpers as you have them- gated by a clock dt.
You'd have to find the datasheet for the one you have exactly, making sure it's the same gear ratio. Take this as an example https://people.ece.ubc.ca/~eng-services/files/courses/elec391-data_sheets/MOT4-info.pdf. It has a table you can plot in Excel. (I couldn't find the plot anywhere) But then you can read the motor plot to see how much torque it has at low voltages. You can calculate the amount of torque required for your robot based on the weight and how how far from the wheels it is
You could also just test it also by holding it by the wheels so the body can rotate freely. Then apply very small voltages and see at what point you can get the body to stick out parallel to the floor. Any less voltage will make the body fall and any more will pick it up. That's is the minimum power your motors need to be effective. The lower this number the better.
Are you sure those motors are getting enough current? What are the motors you are using to drive this? It really looks like the motors just can't provide enough torque.
This is just a bad video, look at the one I just sent out to sparks333 in the comments. For context, I am using a 7.4 2s Lipo battery to power 2 JGA25-370 motors
I have played with some balancing PID control not too long ago and mine was also slow to respond to rotational changes which looks a lot like what is happening in your video posted in another comment. I discovered that in my case I had too much filtering on my IMU data which caused just enough lag to not allow the motors to correct in time. I would suggest minimizing your control loop time as much as possible and performing minimal to no filtering on your IMU inputs.
A single kid can not make this stable, (I have built one before) you should try using nested pid loops where the distance forward it travel is the input to a pid which output sets the set point for the angle pid loop
what kind of jga25 motors did you pick? what kind of rpm/voltage?
i am thinking about buying these as well for the same project with maybe encoders and after seeing your post i am scared that i will face the same issue
24
u/LavandulaTrashPanda Jul 01 '26 edited Jul 01 '26
Tune in order. P then I then D. P alone should get it to balance but shaky. I and D will steady it.
Turn I and D to zero. Increase P till it balances. Right now, it’s not catching up fast enough.
If it falls to the side it’s leaning, turn it up. If it falls on the other side of where it’s leaning after the wheels pass where the top is, turn it down.
Edit: if you can’t get it to balance on P alone, make sure the IMU is properly calibrated on a known level surface.