top of page

4 Bar Linkage Mechanism 

Created a four-bar linkage, as shown in the images below. The transmission was a gear train attached to a 6-wire stepper motor. 

The goal of this mechanism was to be able to orient itself in space, move to a desired encoder count, and hold there for a certain amount of time. Then, it would get directions to go to a different point in space, and the mechanism would move to that point. 

The points in space it would move to were determined by a board used in my college lab. This board had a series of metal rivets (I called them flags) that could go from 0-90 (90 being and upright position). Below every flag, there is a photoresistor to detect light. Once the light is detected at that spot, the flag can go down. On either side of the series of flags, there are proximity sensors that can be used to detect if a flag is up or not. 

Major Problems 

  • Joint Design 

    • I wanted my joint to be completely frictionless 

  • Calibration / Encoder Count variants​

    • As the system operated, the encoder counts got less accurate 

  • PID Controlling ​

    • How do I get the correct P, I, and D values so that the mechanism itself does not ​shake/ go too slow / overshoot my encoder count targets

Solutions 

  • Joint Design

    • I added thrust-bearing washers to reduce friction & handle any axial loads of compression in the joint. Then, I made the linkage itself threaded. 

  • Calibration / Encoder Countrs being off over time 

    • I added a simple limit switch and blockers so that they traveled within a known range of motion. Whenever it hit the left edge of that range of motion - the limit switch would be hit and in the code, it would calibrate back to zero. I would also tighten the set screw on my driven gear after every trail to ensure I was getting accurate encoder counts

  • PID Control 

    • Went back to my first principles of P, I, and D control- knowing that each can fix steady-state error in the current, present, and past (respectively). Then I tinkered around with the mechanism and the numbers for what seemed like forever. I ended up adding things like frictional constants and wait times in order to help control of the mechanism. The derivative control did a good job of getting rid of the shaking/dampening of our oscillations, while the proportional control made the range of the oscillations constant. The integral control got rid of errors that came up over a long time. 

Next Learning Steps - 

I started to get interested in how you can continuously recalibrate the machine, and make it so that the machine will constantly be able to adjust to changing external factors. The biggest factor that was constantly changing was the fact that we had 2 set pins that were keeping our driven gear attached to the axel. If the axel slipped at all, it would mess up our encoder counts that were driving the rest of the system. I would tighten the set pins (by hammering them back in) before every trial just so I could get consistent results to compare my chosen values for PID. 

The major problem I faced in trying to account for small changes in my environment was that it was so dependent on the action done /how hard the motor worked. I almost needed to be "tallying up" the wear and tear on my gears at every point in time. It was easy to model in some scenarios - but proved incredibly different in others. I got a bit into Arduino code and decided to save the project for my advanced controls class.  

I am also trying to ideate ways on improving the accuracy of the proximity sensor while keeping it at the same price (I did not want to make the system really expensive). The proximity sensor would pick up a lot of false values - and I wanted to try to add a filter in my code that can filter out fringe edge cases that would mess up my code. Still ideating on how to build a better filter. 

hsDGAycxDtNngJ_hT3_n7GduTlV-6g0aVdPmRRsWAXyImtzegTw3DwcQ9e2VUFI8OZt0-M_xN6bSbWD4lylpigbeEW
gPdlZwiIIVHUSC-osUgPwotpHx7ih_bTr932uOOVkTUQS-ZrNGPvnCL0j7wWbXXk3o6a6yRv7ti7dJV3AVf8yVrSBW
bottom of page