OpenServo.com Forum Index OpenServo.com
Discussion of the OpenServo project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Velocity control without potentiometer

 
Post new topic   Reply to topic    OpenServo.com Forum Index -> Software
View previous topic :: View next topic  
Author Message
stefanengelke



Joined: 03 Jan 2006
Posts: 59
Location: Stuttgart, Germany

PostPosted: Wed Apr 16, 2008 2:40 pm    Post subject: Velocity control without potentiometer Reply with quote

Hi all,
it has been a while since my last post in this forum. Working every day is such time consuming. I want to be a student again Smile

You guys did a great job with version 3 of the OpenServo board. Last weekend I finally found time to play a little with the new boards. The first new feature I've taken a look at was the back-emf measurement.

Test Setup
To see the quality of the measured back-emf signal I've connected the OpenServo board to an test bench I've build for an robot drive. The drive consists of a 3-6V DC motor and a gearbox. The shaft of the gearbox (where normally the wheel is mounted) is connected to a rotational sensor (in fact just an old ball mouse). Both signals are polled by an extra ATMEGA168 (back-emf over I2C from the OpenServo and angle over PS2 from the old mouse) and are send over RS232 to the PC.
Here is an picture of the test setup:



For the software on the OpenServo I've used the AVR_OpenServo_V3-dev but disabled the PID algorithm so I can set a command PWM to the motor. With this setup I've tested different PWM values. As Barry has mentioned in an other thread I could also observe a large noise on the back-emf signal.

Improvement of signal quality
So the first thing to do was tuning the two parameters REG_EMF_COLLAPSE_DELAY and REG_EMF_CHARGE_TIME. For this purpose I've calculated the standard deviation of the back-emf signal in steady state condition (motor was turning with constant speed). The standard deviation is nothing else then the sum of the quadratic deviations from the mean value at every time stamp. So this value is more or less proportional to the strength of noise. Unfortunately the optimal parameters (both 3) were just next to the default vaules (2/3).
The next step was filtering the signal. I've implemented a simple filter which calculates average of the last N samples. This can be very memory consuming because all the last N values must be stored. But with N=10 samples the signal was already pretty good how you can see in the following diagram:



You can see the motor velocity plotted over a short time inverval. The dashed curves is the velocity measured by the mouse and the dotted curves is the back-emf signal. The different colors are different PWM values started from 20 to 60. The fluctuation in both curves (back-emf and mouse signal) is because of the friction in the gearbox varies. You can even hear that the motor is not turning with constant speed. Furthermore the velocity signal from the mouse is not as good as I thought. Indeed the position is sampled pretty accurate but differntiate the stepped position is not as easy. I definitly have to improve the filter. Anyway the plot shows a realy good linearity of the back-emf signal. I've scaled the mouse signal so that the curves fit at 20 PWM and as you can see also the other curves fit pretty good.

Control of motor velocity
Surprised by the good linearity of the back-emf signal to the real motor velocity I wanted to see if it's possible to control the motor velocity only with the back-emf as sensor signal. Based on Mike's P(I)D algorithm for position control I've written a PI+FF algorithm for velocity control like proposed by Barry in this thread http://www.openservo.com/forums/viewtopic.php?t=689.
Putting all together the velocity control is working suprisingly good. I've tried to catch the behavior of the controlled motor on a video but you can't really see how fast the motor is turning. I will do some measurements of the controlled motor the next days so I can show some plots soon. Anyway I will use the new OpenServo V3 for my robot drive because with an underlying velocity control the main controller does not have to take care about friction.

Thanks for this great peace of hardware/software!!

-Stefan
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Thu Apr 17, 2008 10:38 pm    Post subject: Reply with quote

Hi Stefan,

It has been a while, but you do like to come back to the forum with the good stuff.

Thanks for taking the time to plotting out all of the back-EMF details for us. Nice work.

Quote:
The next step was filtering the signal. I've implemented a simple filter which calculates average of the last N samples. This can be very memory consuming because all the last N values must be stored. But with N=10 samples the signal was already pretty good how you can see in the following diagram:


I would be interested in seeing that working. If you notice, the current back-emf code uses the bemf value and filters it through a simple lowpass filter. This seemed to take enough off the top of the back-emf noise to make it work in directly in the PID algorithm.

I was also surprised at the linearity of the output considering the noise and the method of reading.

Quote:
Surprised by the good linearity of the back-emf signal to the real motor velocity I wanted to see if it's possible to control the motor velocity only with the back-emf as sensor signal. Based on Mike's P(I)D algorithm for position control I've written a PI+FF algorithm for velocity control like proposed by Barry in this thread http://www.openservo.com/forums/viewtopic.php?t=689.


I would love to see how you implemented this, at least without having a multitude of variables to tune. Patches welcome Smile

Good to see you, Stefan,

Keep up the good work Smile
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
stefanengelke



Joined: 03 Jan 2006
Posts: 59
Location: Stuttgart, Germany

PostPosted: Sat Apr 19, 2008 11:50 am    Post subject: Reply with quote

Hi Barry,

good to see you! It seems you are doing most of the administrative stuff for the OpenServo project at the moment. Thanks for carrying this great deal of work.

Quote:
I would be interested in seeing that working. If you notice, the current back-emf code uses the bemf value and filters it through a simple lowpass filter. This seemed to take enough off the top of the back-emf noise to make it work in directly in the PID algorithm.


I've used an older version of the development branch to implement the velocity controller. In that version the filter wasn't used for back-emf and so I've implemented the simple average filter. Anyway this gives us the chance to compare the different algorithms.

The first test was to see the effect of the shift parameter in the simple lowpass filter as used in the current OpenServoV3-dev version. To see both steady and dynamical behavior I've disabled the P(I)D controller for position control so the PWM to the motor can be commanded. The test is starting with PWM=0 and after 0.5s it is stepped to PWM=100. After another 2s the PWM is stepped to 180.



In a second test I'm comparing the simple lowpass filter with my algorithm which calculates the average of the last 10 samples. The setup is the same as in the test before.



The first peak you can see is a disturbance caused by the sudden jump of the voltage and can be observed also with the other filters. I've sampled the measurement data 3 times for each filter configuration and plotted them afterwards. The average configuration is the only one where all curves are showing this peak but I don't think it's cause by the filter algorithm.

Summing up both algorithms provides pretty much the same results but I will use the lowpass filter as from now because it's much more elegant. Smile

Quote:
I would love to see how you implemented this, at least without having a multitude of variables to tune. Patches welcome Smile


For better documentation I've written a small description of the control algorithm:
http://www.tinkerer.eu/OpenServo/VelocityControl
Perhaps we can put it onto the OpenServo Wiki.

At the moment I'm planing how the pure velocity control can be integrated into the current OpenServo framework. Since it is no servo control anymore there are some files where we need to check defines to enable the appropriate piece of code. Do you think it makes sense to integrate it or should I upload it to a new branch on the CVS?

- stefan
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Sat Apr 19, 2008 12:53 pm    Post subject: Reply with quote

Hi Stefan,

Quote:
good to see you! It seems you are doing most of the administrative stuff for the OpenServo project at the moment. Thanks for carrying this great deal of work.


Since Mike left I have been carrying the torch on the project. Lets just say I am glad my code works, the item you ordered in the shop arrived, and the new website isn't too bad Wink

Quote:
Summing up both algorithms provides pretty much the same results but I will use the lowpass filter as from now because it's much more elegant.


Great work. Looking at the graphs for the low pass filter, it looks like we are calculating a value below the true value for a filter level of 1 (current default). Filter level 2 and three seem to give the best results, would your findings support that? If so we should change it.

Quote:
At the moment I'm planing how the pure velocity control can be integrated into the current OpenServo framework. ... Do you think it makes sense to integrate it or should I upload it to a new branch on the CVS?


There is a feature freeze on version 3-dev so it is better in a different branch for now. In the not too distant future there is going to be a rollup of of branches, as we have far too many already. When the time comes to do that we can move you branch into the new 3,1 branch.

Additionally I am planning a whole set of algorithms for cascaded velocity control for the 3.1 branch. This branch will also support unlimited rotation and encoders, so remember to account for that.

The document looks great. Feel free to add it to the wiki, and find a suitable place to link from.

Thanks again!

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
stefanengelke



Joined: 03 Jan 2006
Posts: 59
Location: Stuttgart, Germany

PostPosted: Sat Apr 19, 2008 1:37 pm    Post subject: Reply with quote

Quote:
Looking at the graphs for the low pass filter, it looks like we are calculating a value below the true value for a filter level of 1 (current default). Filter level 2 and three seem to give the best results, would your findings support that? If so we should change it.

I've forgotten to say that each curve is measured independently. That means that the different filter setups are not filtering the same signal but a new measured one so we can do only a qualitative comparison. Anyway you can say that a higher filter shift causes a slower rise after a jump. So we have to find a tradeoff between remaining noise and time delay. I suggest a default value of 2.

Quote:
There is a feature freeze on version 3-dev so it is better in a different branch for now. In the not too distant future there is going to be a rollup of of branches, as we have far too many already. When the time comes to do that we can move you branch into the new 3,1 branch.

The feature freeze is a wise to decision. Using the OpenServo as velocity controller is a different application anyway. Is the following folder adequate for uploading my adaption to the CVS?
    /OpenServo/AVR_VelocityControl

Quote:
Additionally I am planning a whole set of algorithms for cascaded velocity control for the 3.1 branch. This branch will also support unlimited rotation and encoders, so remember to account for that.

Sounds great. When I find the time I resume the scheme of a state estimator. Now where we have different sensor signals this approach could be really helpful again.

-stefan
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger
ginge
Site Admin


Joined: 14 Jan 2006
Posts: 1030
Location: Manchester, UK

PostPosted: Sat Apr 19, 2008 1:43 pm    Post subject: Reply with quote

Quote:
The feature freeze is a wise to decision. Using the OpenServo as velocity controller is a different application anyway.


OpenServo is starting to control a whole load of different hardware types. There is stepper motor support in the -dev branch too.
Eventually it would be nice if all hardware support was in one (stable) codebase with options of enabling and disabling easily. This is he goal we are working to.
Eventually there will be a page on our server with a configuration wizard that lets you set any options you want, and it generates a hex file and the config files.

Quote:
Is the following folder adequate for uploading my adaption to the CVS?


Yes, that looks good. Go ahead

Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
stefanengelke



Joined: 03 Jan 2006
Posts: 59
Location: Stuttgart, Germany

PostPosted: Sat Apr 19, 2008 6:22 pm    Post subject: Reply with quote

I've uploaded the adaption of the OpenServoV3 software for velocity control to the CVS under the following folder:
    /OpenServo/AVR_VelocityControl

Furthermore I've integrated the documentation into the OpenServo Wiki at:
http://www.openservo.com/VelocityControl
It's linked from the "Docs, Tools & Utilities" page.

I'm now going to integrate the OpenServo boards with the new software into my robot. Very Happy

-stefan
Back to top
View user's profile Send private message Visit poster's website Yahoo Messenger
Kampower



Joined: 31 May 2010
Posts: 7
Location: Hamburg

PostPosted: Mon May 31, 2010 6:01 pm    Post subject: Application in dosing machines Reply with quote

Hi all,

I was wondering how such the servos can be useful in dosing machines. Especially where it is very important that over-dosing or under-dosing is avoided. An example would be in the manucature of powder detergents where the machine has to dose 1000g for instance.

How can this be made possible to 100 % accuracy with the openservo technology.
Back to top
View user's profile Send private message Send e-mail
Nooralam



Joined: 30 Sep 2014
Posts: 1
Location: United states

PostPosted: Tue Sep 30, 2014 6:52 am    Post subject: Reply with quote

My partner and i seemed to be asking yourself precisely how this sort of the actual servos can be useful inside dosing models. Particularly where it is very important which over-dosing or maybe under-dosing is averted. A case in point could be inside manucature regarding powder detergents where the equipment needs to dose 1000g for instance.

How can this particular come in probable to help 100 % reliability while using the openservo engineering.
_________________
http://www.svsu.edu/
vceexam.com
http://www.berkeley.edu/index.html
Back to top
View user's profile Send private message
jharvey
co-admin


Joined: 15 Mar 2009
Posts: 361
Location: Maine USA

PostPosted: Sat Oct 25, 2014 3:37 pm    Post subject: Reply with quote

Haven't login for some time, sorry for the later reply. About control algorithms, one way to prevent overshooting is to have an over dampened system, Those will take longer periods of time to get to the target position, and will not over shoot.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    OpenServo.com Forum Index -> Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group