I already asked this question in another thread, but it seems like this might warrant a good programming discussion.
So let me describe a scenario: Let’s say a robot’s scissor lift with 5 stages is unable to be mechanically stablized via a bar running across the length of the lift, due to the size of the intake and the intake’s contents. Would it be feasible to keep the lift stable entirely via programming instead, like with 1 potentiometer on each side of the lift running a control loop and working together to ensure both sides are completely level at all times? In theory, it should work as well as putting bars across the length of the lift, right? (Keep in mind we haven’t had a chance to assemble our robot yet, and are completely working off of our CAD drawings at this point)
What other suggestions might you have? I was thinking some sort of fail-safe system in case 1 pot isn’t working right, in which case the cortex tests for both analog signals and if one isn’t active, the other pot runs the entire control loop.
This is exactly our major design difficulty. It is not funny to see a five stage scissor wobble. Or kind of, maybe… We are for sure going to have structure support, but programming is also required:
Double potentiometer. These are tuned to report back theoretically same values if the lift is balanced. So with this you can do more interesting things. For example, if the difference between these two exceeds a certain value, increase the output difference between motors on two sides. Or you can establish a function between these two.
Adjustment. We use but never trust program, so we plan to use the two joystick inputs on the secondary joystick to adjust two sides of the lift separately. The input is scaled down so that the max speed is still slow to enable precise adjustment.
We expect the potentiometer to break at least once, so when it breaks, we still need to deal with balance. Of course you need a button to disable the whole potentiometer sensor input processing program. So that when one inputs an infinite value, your lift wouldn’t just be completely ruined.
Finally, LCD. Actually reading both of the values from a screen everywhere really helps with debugging and programming.
Also, we plan to use the average value of the two sides input to do our control loop just in case.
This is our current plan about the lift control system. Of course you can add more, but the balance between complexity and stability is the factor to consider. I hope that helps.
Potentiometers may not exactly track each other (somewhere on the forum we did some tests), so you may need some calibration. I’m still a fan of encoded motors, but then you also need limit switches as they are not absolute. Programming will not compensate for poor build quality so get that correct first.
Thanks guys! I acknowledge that programming won’t make up for a bad build, which is why we’ve been working in CAD for months to make sure our lift is stable on each individual side, but the issue we face is that our intake runs across the entire interior of the robot, and unless I make modifications, I won’t be able to put a bar across our lift, so I was wondering if we could just forgo the bar running across, connecting the two sides of the lift together, and just have the stablizing done via programming instead of mechanically.