Quote:
Originally Posted by Rangel(kf7fdb)
We used a similar type of set up in 2013 for our climbing robot. Because it was such a compact design, our climbing hooks couldnt be mechanically synchronized. We ended up using encoders on both sets of hooks to have one controlled with pid for position while the other side tries to follow the master side. Overall it worked out fine as long as they started in the same place. Whatever you decide to do, I recommend against a potentiometer. That way if you are using any belts or chains, you dont have to worry about slippage or skipping and having to re adjust the sensor or code.
|
I am a big fan of mechanical synchronization if you can get it -- hex shaft and hex bearings have really made this a much easier task...
...but if you can't get it to work, putting the computer in the middle doing the sync can be made to work.
I would actually suggest that you stay away from Master/Slave idea. I would put in independent PIDF loops to control each arm but I would have the RoboRio monitor the situation and take action if the two arms get more than X different.
As to sensors, I am going the opposite direct that Rangel(kf7fdb), absolute encoders like pots are your friend rather than incremental. You'll want your code to be tolerate of pot adjustments (e.g. have a simple way to offset the pots in code rather than forcing you to chase your tail tweaking pot position). The main reason I don't like encoders is that the have the problem of loosing position information when the RoboRio is not paying attention. You'll have to start the arms in exactly the same position each time. If your robot goes brain dead during a match you'll lose your arm position...
That's my two cents anyway.
Dr. Joe J.