@smiller29 You aren’t running into ARC limitations, you are running into regular robotic limitations.

It’s interesting to me that you have made an assumption about the way things should work. What you are attempting is beyond what is standard in the industry. I know this plight as I have had to face it myself. There’s a reason that EZ-Robot servos have stall protection and others do not, we asked the same question as you, Why does this not exist?. I’m not going to lie, it’s a long hard road to go against industry standards or to even start to improve upon them.

Here’s the straight goods, what you are asking for is a challenge that doesn’t have a perfect solution yet. The ideal scenario would be to include in the servo itself the ability to add a sensor (beyond the position sensor it already has: the potentiometer). There are a number of ways this could be done, limit switches, encoders, current sensing, or pressure sensors. Some of these options do exist, inside of servos like Dynamixels and they have the price to match this feature, but for the venerable RC servo these things don’t exist.

Using RC servos comes with limitations because they were originally  designed to just give RC operators precise control over steering and flaps, they didn’t have robots in mind.

Robotics hobbyists use RC servos because they are a cheap gear motor with built-in H-bridge that has positional feedback, and why wouldn’t we?!? They are great, but they are not purpose built for robots. The only way we got around the limitations of servos is with software.

DJ made some damn good software that has made servos do things that have surpassed my wildest imagination of what they could be capable of. I now cannot imagine having to program every single servo position again, I will never go back to that. That level of frustration is a world I’ve left behind. While the software can make the servos do many things, there is a limit to the magic.

I can completely understand your frustration because you are running into challenges I have run into. I’m working on my own ideas on how to solve some of these robotic challenges but those are long term projects. In the DIY or entrepreneurial space, challenges are an everyday thing but elegant solutions are like a fine wine sometimes. Each challenge can be overcome but it does take time, creativity, and grit.

To tell you the truth, my suggestions are merely the tip of the iceberg, there’s a whole lot of solutions I haven’t even considered that are likely just below the surface. You might have to get a little cold, tired, and wet to find them but I assure you that it’s going to be worth it when you do!

@Jeremie,  I agree with most everything you stated above.   The reason I pay for ARC is for the things it does well like the AutoPosition Skill and the scripting options and more.  But like you said we need software to bridge the gaps of the current hardware limitations if it can be done.  To me this could be solved with software.

What I am going to have to do is write script for grasping something. Each finger is going to need call a function with a loop that moves the servo from 0 to 180 one step a time and test the sensor to see if I should exit the loop. Then I need to find a way to call this script as part of a AutoPosition Action.  This is the part I am not sure how to do or if it can be done.

@Smiller29, 

Quote:

Then I need to find a way to call this script as part of a AutoPosition Action

I'm not sure many people know this but you can also place scripts in any or all of the frames of the AP action also. That way the script will not trigger until that frame starts.

Your script will probably need looped "If, else if, else" statements that monitor the ADC port's voltage your fingers sensors are attached to. Then it will stop the servo and it's looping when the voltage gets to the proper reading that reflects the max pressure you are looking for.

I hope I understand what you are trying for here and this helps.

I need to be able create an AutoPosition action that really does not move servos but would trigger a script that would cause the fingers to close while at the same time it is testing the adc ports related to the fingers.  I am not sure if you can do this.  Meaning if the AutoPosition frame/action has the servos set at zero position can the script make them move to 180 position or would there be a conflict?

This is a very interesting topic and thread.

@Smiller29, my advice to solve this would be to experiment and make the experiment as simple as possible to see the results.  Don't think about 10 fingers, and 10+ servos with 10+ sensors, think of one servo moving a gripper with one force sensor.

With one servo you could use AutoPosition or not use it because you could drive the servo to close or open in a script.  Likewise, you can read the sensor data in the script and tell the servo to stop before you stall the servo or squish the object.  This would let you play with timing of moving the servo and reading the sensor and it would inform you if the force sensor is going to work as well as expected.

I think this would refine the final solution.  I would not focus as much on if AutoPosition can or cannot solve the hand grabbing of an object part of the question.  Because AutoPosition can certainly control well 10 fingers in choregraphed movement, and you have the power of adding a script inside the AutoPosition Action if needed or integrating the AutoPosition Action in an outside script.

The question I think is, will my sensor work as well as I think it will and what is the best way to script the use of the sensor?

I was actually going through my collection of servo magazines from 2015 and not only were there articles on Alan in there (from Will Huff, a fellow member) but also a really neat robot from John Blankenship (another member) that discussed grippers and sensors to make for smart grasping.  John's solution included multiple gripper sensors including force and IR.

This is why this is such a great topic because not many folks tackle the problem of making grippers or hands smarter. 

@Justin,  I agree I am only working with one finger right now but at the same time understanding what the end solution needs to provide.

This is the way I am looking at this problem for starters.  I will use standard AutoPosition actions and frames to animate the hands for any movement that is not trying to grasp an object.  But when I want to grasp an object using all five fingers I need to call a script that can move each servo from 1 to 180 degrees 1 degree at a time and test the force sensor to determine if I have reached a stall pressure and need to stop moving the servo.

I know I can do that in arduino code I just need to duplicate that logic in ARC.

The other thing that I am also doing is to use dc motor gearbox with 3mm screw drive to replace the servo using and servo board and pot for position and direction management.

The goal is to make a strong useable hand with adaptive fingers that can crush a can if told to or hold and egg without breaking it.

@smiller29, Have you experimented with just the sensor?  Are you finding it responds as you'd hoped?

For example, I have this flex sensor and when I connect it to only a multimeter set to resistance measurement and test it by pressing the flex sensor in my fingers, it does change resistance from no reading when not touched to 80K with a light touch down to .1 when squishing the sensor as much as I can between my fingers.

But it just didn't respond very fast, which could be my meter's refresh rate I suppose.

I'm going to try my own test with it in a gripper to see how it responds with ARC reading the value from it.

Somewhere in my parts stash I also have this flex sensor which I have wondered about for use on a palm or gripper.  I have never used it before either.

You’re using the incorrect hardware for the job. Use a servo that provides some feedback. Dynamixel servos will give you feedback based on the amount of torque required. You can monitor that.

I don’t know why you keep trying to say limitations of ARC in your threads haha it’s impossible to have a limitation of ARC because ARC is a programming environment. That means absolutely anything that can be programmed can be achieved in arc. The limitation is not arc

so pwm servos are very limiting. Unless you want to add some closed loop controller that monitors the pwm servo consumption - or a pressure sensor. Either way it wouldn’t make sense to add a tight loop to ARC - id suggest a little micro on the servo. But again - my real suggestion is to use an appropriate servo that has the features you need such as a Dynamixel servo. Or maybe Feetech as well?

im a fan of adding little micros like ardunio to do tight stuff on closed loop monitoring. But the real Challenge we’re up against is lack of products for these kind of solutions. Pretty much everything after a point of your robot build needs to be customized. We eventually run out of off the shelf parts for these kinds of things.