# Map arm movement (as plant) to lidar-measured distance (as setpoint) using PID

I am trying to control the arm of my setup such that its tip is at a particular distance from the surface. That's when its supposed to stop.

The actuator has no feedback, so I use a 1D LiDAR to measure the distance of the arm from the surface. Currently, I ask the actuator to keep lowering the arm until it has reached the desired distance (target_d for example), which is actually measured using the lidar. As the actuator is basically kind of bang-bang controller, I have only 2 options: ALL GAS or HAND BRAKES.

I am trying to use a PID to contol this. The issue is, the error is obtained as distance (in mm) and the input to the plant is time for which the actuator fires up. Can I have a PID or any alternate controller to achieve fast and accurate actuation without having to oscillate around the setpoint ?

• How rapidly can you control the bang/bang output? And what in the world is this thing, actually? Be specific about the actuator technology. What leads you to believe it's a suitable setup for achieving the goal? Oct 21 '20 at 16:56
• I can send the commands to the controller at a max rate of 250kbps via CAN. The actuator is this linear actuator or a slight variant. I have chosen the actuator as it is easy to use and was readily available to me. Oct 21 '20 at 17:15
• Your actuator is fine, it's your drive electronics which are utterly unsuitable. Get the version of the actuator with encoder and give it a proper servo drive. Or even open-loop, a remotely decent motor driver would give you something other than "full speed ahead". You either misunderstand, or desperately need to replace whatever box is sitting between that DC motor and the CAN bus. Use the right tools for the job, not the wrong ones! Oct 21 '20 at 18:04
• If I were to keep only the actuator (which probably also has an encoder/potentiometer with it), what should the other circuitry be, to have a controlled arm movement ? Oct 22 '20 at 3:20
• A servo driver, ideally one which takes a position command and achieves it, or at least one which takes a velocity command and closes that loop. Worst case, something that takes an open loop directional throttle type command. Oct 22 '20 at 3:39

I think the two biggest concerns here are 'gain' and the bandwidth requirements of your system.

Without regulating the force applied to the lever arm from your actuator (bang bang) you will always be moving the arm with max acceleration, meaning you can't impose damping on your system through the control input, so it inherently has an enormously high gain.

You also likely have the issue of LiDAR limiting the bandwidth of your control loop; you can poll a position sensor orders of magnitude faster than the turnaround time for LiDAR frames.

I see in a comment that you are using a linear actuator, with some kind of CAN capable motor controller. Ditch the bang bang control. DC motor controllers are dirt simple. If your current one can't change the speed of your motor, you won't have difficulty finding one that can. Then instead of using time as your PID control effort, you can use motor voltage (or current if you buy a higher quality controller).

I also recommend ditching LiDAR in favor of an angular position sensor. I have spun out my own contactless magnetic angle sensors that are great for robotics (continuous angle output, retain the same angle across power cycles). You'll get higher bandwidth and resolution than with LiDAR. It looks like the linear actuator you're using also comes with encoder options, if you don't want to make your own.

• How would the angle sensor help me getting the arm to stop at the exact setpoint ? I can't understand. Oct 22 '20 at 3:18
• forward kinematics. if you know the arm angle, and you know its position relative to the table, you know everything necessary to determine the distance of the end of the arm to the surface of the table. All position control for robotics is done this way; if vision is used at all, it's on a 'higher level' (figuring out locations of objects not attached to the robot...) not for the low level task of figuring out the configuration of its arms Oct 22 '20 at 4:26
• But isn't the error computed by controller (distance in this case) and the input to the plant (angle in this case) not supposed to be of the same units (like mm or degrees)? Oct 22 '20 at 5:33
• that's called inverse kinematics. in the case of your arm, there is a simple closed form relation between the arm angle and the end effector position Oct 22 '20 at 18:11