Controlling the position of a Variable Speed Servo.

Hi there, I am working in a school project and I need some help, I hope you can help me :grin:

I have to do a Robotic arm that writes in a flat surface. The robot have two angle Joint. But I bought two servos with variable speed. I can change the angle speed of the servo, but I cant control directly the position of the shaft.

Do you know a library or a code that could be helpful to my project? I do not know what to do, I dont have the money enough to buy the servos that I need. Thanks in advance.

Greetings!

HI,
Can you post a link to the spec/data of the servo please.

Tom.... :slight_smile:

I can change the angle speed of the servo, but I cant control directly the position of the shaft.

Sounds like a continuous rotation servo. If it is, then it cannot easily be modified to be a regular servo.

If you want position control just buy two regular servos. You can control their speed using the concept in the servo sweep example.

...R

You know your velocity, you know the time.

Integrate.

1:1:
You know your velocity, you know the time.

Integrate.

I don't believe that could be done with sufficient accuracy to draw pictures - indeed I doubt if it could be done at all with any useful degree of accuracy or repeatability.

You don't actually know the velocity which will be affected by friction and variations in the load.

...R

Depends how well the servo tracks the velocity command.

Its worth a try, and certainly educational.

By servo do they mean hobby servo (that uses Velo command??).

Or servo proper? ...that uses an encoder and the loop is closed in the arduino? ...in which case, you have exactly what you need - ie the I in PID :wink:

Either way, encoders could solve this.

OP, are the kinematics (the 'math') to to translate xy position to the 2 rotational joints already given?

1:1:
Depends how well the servo tracks the velocity command.

It's a school project so there is a 99.9999999% probability that it is a hobby servo.

Sorry, but I think you are over-complicating a school project.

I can't imagine the "how well" being anything other than "badly". Have you a continuous rotation hobby servo that provides a consistent predictable speed for a given servo.writeMicroseconds() value regardless of load?

...R

Yes, likely... (Its a hobby servo, but no I dont have one)

Just the 'variable speed' kinda made me inquisitive.

I've never played with continuous modified hobby servos - how are they variable speed?

I thought with the removal of the pot they'd just drive 100% effort - i.e. one speed (once they're at speed) - and therefore effectively have a pretty basic command:

  • This way
  • Thatta way

If they do indeed have variable speed (open loop) I still maintain it'd be a educational exercise to see how accurate integration could be - and no that complex at all... Maybe a math teacher could appeal to their intuition with questions like 'if you go 100 miles in an hour - how far will you go in half an hour?'

Hrrrm, are there programmable ones that convert pulse width to speed?

I think the arm will be something similar to the below.

1:1:
how are they variable speed?

I thought with the removal of the pot they'd just drive 100% effort -
.....

If they do indeed have variable speed (open loop)
.....

Hrrrm, are there programmable ones that convert pulse width to speed?

Not really a strong knowledge base from which to suggest solutions for school kids ? ?

If they do indeed have variable speed (open loop)
....

  • and no that complex at all..

Well let's see an example of your "not that complex code" based on a hobby servo

You are mixing up theory and practice.

...R

Whether or not I have used a continuous servo is immaterial to the statements I've made - I feel like I've been pretty conditional anyway.

I suggested a 'variable speed open loop servo', which may or may not be a 'hobby servo' depending on circumstances - :wink: - anyways, IF you have a 'hobby servo' that operates such that a command say of 100 will drive it full speed ahead, 0 no movement and -100 will give you full reverse (or whatever numbers you like but the point being they are linearly mapped)

AND, for all directly humanly observable intents and purposes it appears to do exactly that

THEN, it might be educational and interesting to test this observation and see some theory in practice.

It's as simple as:

estimatedPosition = estimatedPosition + currentSpeed * samplePeriod; //but you knew that right ... :drooling_face:

And then depending on the level at school they can do quite a bit with this:

  • Play with the sample period - see how faster is 'more accurate' - notice how this relates to limits approaching 0 in calculus.
  • Notice how a sin input to velocity has will have a -cos position.
  • feel free to add your suggestions!

I'm still not sure if they are using kinematics to relate XY positions of say text, or line drawings to the two arms (that is IF, they are like the youtube videos ... that at full extension have a singularity by the way).

IF not, then their writing is going to be made up of circular sections at the radius of the arms, fun for a while and they get some good practical skills building it (you'd hope they get to build it) - but again, I think, there are good opportunities for theory to be 'integrated' ::slight_smile: :smiley: into the project in a: 'I didn't even realise I was doing university level math!' kind of way.

1:1:
estimatedPosition = estimatedPosition + currentSpeed * samplePeriod; //but you knew that right ...

That's the theory.

Where does the value for currentSpeed come from ? (that's the practice bit that will IMHO fail).

...R

From the velocity command.

I should have used veloCommand as the variable...

estimatedPosition = estimatedPosition + veloCommand * periodSinceLastVeloCommandChange

As I've mentioned the idea is to try it - experiment. If it 'fails' it's still educational.

:wink:

1:1:
As I've mentioned the idea is to try it - experiment. If it 'fails' it's still educational.

You try it and report your results.

...R

aww come on - stop being such a negative nancy ! :grinning:

Anyways, I suggest all this as I have done it...

We ran the same style arm as in the youtube videos but playing with sliding mode controllers in labview - using velocity command (and with the kinematics) we could compare estimated (i.e. integrated) trajectories with the actual drawings on the page.

It was poop! (SMC (sliding mode) isn't the most intuitive concept to bash your way through in limited time)

But, it was interesting and educational.

Any student heading off to (at the least that I am certain of) physics, engineering and applied math will learn about numerical methods and data acquisition sooner or later. This would be a nice applied intro to that.

Anyways, I plan with my kids to throw in a little 'theory' like this whenever the opportunity arises - whatever the subject. Nothing like physical relevance - combined with fun - to get the beginnings of an idea across.

As for the original query - in lieu of the servos you suggested (that he cannot afford) and considering the lack of specifics ('servo'?), I think I answered it as generally as anyone could :slight_smile:

1:1:
that he cannot afford

To be truthful, I missed that bit.

But servos are not very expensive and I am convinced that your way will not work for the OP’s project.

…R

The crickets chirping from the OP's direction are met with what remains once my idea is taken out of consideration...

Hrrrrm, maybe you and I could buy the kid some hobby servos? That might get him/her posting again ::slight_smile: :wink: