Some big updates to the robot!
I have finally bought a 3d printer and have been busy making parts. I designed columns to support a second deck and secured them to the chassis with m3 bolts and nuts. I used a clever technique where the nut sits inside a recessed space and are held in place by the material, this way it acts as a threaded insert and doesn’t require a wrench. Then I printed a 2-part deck for the robot, my printer wasn’t big enough to do the whole thing in one go.
So now I can finally mount the raspberry pi and its battery securely. The battery sits inside a pocket and the raspberry pi sits on top of that. I don’t have standoffs, so I decided to just screw it on and use nuts for spacers. Might need to add head sinks to the pi too, hopefully it won’t melt the plastic or anything.
So now that everything is secured, I can test the driving capability without worrying about everything falling off. Woohoo!
On the electronics side, I figured out how to get a reliable reading from all 4 encoder, so now I have a position count.
I have also made a PID controller, to control the motor. Otherwise, its impossible to get them to stop when you want. It seems that they keep spinning past the cutoff time.
The key insight is that you can make a template in C, that can be applied to the same function with different parameters. This allowed me to clean up the code significantly.
So, after I figured all of that out, I managed to set a position target for each wheel. The PID performance was still a bit inconsistent, but it kind of worked. The problem is that I don’t want the robot to move at maximum speed towards each target and I’m not sure how to use the kinematic equations with a position target. Plus with speed I could use the teleop_twist_keyboard node, which would let me set a speed with a keyboard and pass the twist message to my kinematics equations which could then pass a motor velocity to the Arduino.
So now I am trying to get a reading for speed. And oh boy that is a can of worms and a half. Basically the most reliable method is to count the number of pulses from the encoder within a specified time interval
d/delta(t)
The problem is that my encoders are incremental. Which means that they go up in discrete steps. Think of it as walking up a staircase instead of a hill.
And that creates a TON of noise, when you try to calculate velocity. The typical solution to this problem is to implement a low pass filter that will filter out the high frequencies and keep the low ones. I tried an update equation from a low pass filter of 25Hz, and that made the signal a lot better. But I have this problem where my filtered velocity doesn’t reach the target, and the unfiltered velocity peaks at the target.
I have no idea why this is happening. Maybe I’m setting a target too high? I can experiment with slower velocities? Creating a low pass filter on the Arduino feels like trying to paint the Mona Lisa with blood spurting out of your cut off finger. Very painful and ugly.
So I’m considering just passing the encoder readings to the pi and letting it do the complicated signal processing and maybe even the control. I’m just worried it won’t be fast enough. The whole point of the Arduino was to have fast low level control, which it seems I can’t do without a better filter! AAAAA!
It sounds like I have to get back to the complicated math of my 4th year control systems course, and get into stuff like Discrete Fourier Transform and Bode diagrams.
Hopefully, I don’t need to get to much into the weeds, I just want the speed control to work.
I am also experimenting with a higher baud rate, might be faster.
In more happy news though, I got the teleop twist to work! I figured out how to use a MultiArray message to communicate to the Arduino and now I can drive the robot with my keyboard on my laptop!
It has an issue with stopping for some reason. It doesn’t like to come to a complete stop. And there seems to be a delay between the keyboard input and the wheels.
No comments:
Post a Comment