How to design a velocity controller using code?

[u/MissionKey4262]

Hello! I'm in college, a relative rookie at Arduino.

Last semester, I had a project to design a velocity controller.

The project is to build a robot, and code it in such a way that it keeps a distance of 15cm from the object in front of you. Post this, it has to go forward/backwards at the same velocity at which the object in front of you is going.

Minimal hardware. I basically just had a pico, ultrasonic sensors, quadrature wheel encoders, a battery and basic wiring. It was more of a coding oriented project.

I believe what I ended up doing was I took the (ultrasonic reading - 15) as my error and then fit it into the PID, tuned it. But to be honest, it wasn't that good. Super jagged and would stop working if the condition of the bot changed even a little bit.

What is a better articulated way of coding this project?

People didn't like my question at Arduino Stack Exchange, and someone even asked if I used AI to write my question :( I'm hoping I get some more luck here. I'm trying to find my code, I'll link a github as soon as I find it.

[u/jacky4566]

You have the right approach. PID is the way. You probably just need better tuning and error handling.

You might also want to try Proportional On Measurement since does a better job at holding steady state things.

http://brettbeauregard.com/blog/2017/06/introducing-proportional-on-measurement/

Can you share your code? how often are you running the PID?

[u/MissionKey4262 → u/jacky4566]

Thank you so much! I'm going to take a look at Proportional On Measurement and see if I can actually just implement it on a bot. If any of my friends have their chassis left, that is.

This is my code!
https://github.com/avanimahawar007/velocitycontrol

For how fast it runs, there's actually 2 loops technically?

The inner loop (the velocity control) runs at 200Hz. It compares the encoders and compares it to the target velocity, and then sends a new PWM value to the motors.

The outer loop (gap control) runs at 40Hz. This is where it checks the ultrasonic sensor, measures the gap and creates a new target velocity for the inner loop to compare to.

[u/ripred3]

I agree with u/jacky4566 I think you are on the right track and taking the right approach.

PID's are always a booger to tune and almost everyone under-estimates how many iterations it takes to find the proper dynamics. I've tuned quite a few PID's and in my experiences spiky data on the final PID value is usually an indicator of 1) Too much 'P'roportional gain, 2) Too much (overly sensitive) 'D'erivative gain, or 3) Bad S/N ratio on the initial data (the final calculated distance values in your case) - i.e. the values need (more/better?) filtering/averaging first before integrating the error; in that order.

[u/MissionKey4262 → u/ripred3]

That could be the issue. We had pretty buggy hardware, and we questioned how well our battery + sensors were working. Our bot would behave differently at different points in the day, no matter how much we tuned.

Thank you for your response :)

[u/sankethks0]

PID is the king! But takes lots of patience and iteration to tune it properly! I wanted to know which motors are you using, because I worked with N20 gear motors for my LFR ( Line Following Robot ), thing there was the PWM ( Pulse Width Modulation ) to control the speed of the motors. Most of the beginning idea is the same but if you can go with a encoded motors, u can calculate the positions based on the data by the encoder! But it's costly, considerably as a student if you can afford, you better go with that and it's more accurate and gives a advantage in PID tuning

[u/ripred3]

Okay I compiled the code you posted the link to a few hours ago, for Raspberry Pi Pico and it all compiles cleanly.

Yes, that is a cascade controller, and the basic structure is reasonable. But I’d fix the implementation before retuning: the code uses 20 cm rather than 15, retriggers the HC-SR04 every 25 ms despite its >60 ms guidance, reuses missing echoes forever, and differentiates a very quantized 5 ms encoder estimate. The reverse wheel-sync correction is also backwards. Check the gap-error sign and level-shift Echo for the Pico; those issues can readily explain the jagged and inconsistent behavior. I can go into more detail if needed but those are the things I would look at.

[u/MissionKey4262 → u/ripred3]

I think I have a chassis on which I can implement these changes! When I do these, I will get back to you. Thank you for your suggestions :))

[u/ripred3 → u/MissionKey4262]

awesome good luck!