Notifications
Clear all

Using encoders for speed detection

19 Posts
4 Users
5 Likes
547 Views
ElectricRay1981
(@electricray1981)
Estimable Member
Joined: 11 months ago
Posts: 121
Topic starter  

Hello all,

It's been a while I posted something I have been very bussy with understanding ROS and this goes pretty fine. But for my project I still use a Arduino which I will use for speed detection and control my motors. Offcourse the DroneBotWorkshop has awesome tutorials and I used one to play around with the speed detection done by encoders built in the motors I have bought. There is a great tutorial n YouTube Using Encoders which I have followed and it works perfect. But now comes my question in the example code in this video at around 24:49 there is a constant TimeInterval which is 1 sec. But as far I understand this means that the detected speed is only updated every second. And if one wants to use this for speed control I think it would be better to make this interval shorter, am I right here? Maybe it would be better to make it like 100 ms for example? 

What is your opinion about that?

 

 

Grtz,
Ray


   
Quote
robotBuilder
(@robotbuilder)
Noble Member
Joined: 4 years ago
Posts: 2065
 

@electricray1981

Rather than counting how many pulses occur per second perhaps you can count how much time passes between each pulse?


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Estimable Member
Joined: 11 months ago
Posts: 121
Topic starter  

@robotbuilder 

I have done that hence all the previous posts I made where we were figuring out what went wrong with my speed detection and PID control. 

I even beleive that you were one of the person that recommended to count pulses over a fixed time interval in the same thread 😉

Grtz,
Ray


   
ReplyQuote
(@davee)
Noble Member
Joined: 3 years ago
Posts: 1432
 

Hi @electricray1981 (&@robotbuilder)

   I have only glanced at the part of the video you refer to, so my comment might not be relevant, but the general quandary in such situations depends on what information is most important to you.

If you look back a little on the video, you will see a scope pattern of pulses which is fluctuating in time to some extent. At the random point I 'froze' the picture, the pulse time was about 1.5 millisecs, which is around 670 pulses per second.

Now even if the speed is constant, as you can only count an integer number of pulses, it is quite possible 3 consecutive readings will be something like 669, 670, 671, depending on the angles that the encoder is at for each of the 1 second periods.

(In the video it looked as if the pulses were a little irregular, so the range of counts would be greater than this fictional example, and this would magnify the effect, but for now let's stay with just the inevitable fluctuations.)

Hence in 1 second, it counts about 670 pulses, and a change of 1 pulse in the count on the next period, to say 669, will only suggest a speed change of about 0.15%, which probably won't be noticed on a display.

However, if you reduce the sampling window to 100 milliseconds, then the counts will reduce by a factor of 10, so two consecutive readings might be 67 and 66. This suggests a speed change of 1.5%. This probably will visible, and could easily be distracting.

And to push the argument further .. you might want to reduce it to 10 milliseconds .. so that readings are now based on 7 and 6 counts ... a change of around 15%.

----------

So, to your question, reducing the time interval would indeed make it more reponsive to speed changes, but it would also make it more vulnerable to the quantisation limitations of counting an integer number of pulses, and if you take this too far, your speed display will degenerate towards a random number display.

Hopefully, you will now understand you are delving into a common engineering type of problem, where you start with best estimates, but typically also have to do some 'fine tuning' for the optimal result when you have all constructed and working.

I suspect Bill chose a time of about 1 second, to get a reasonably stable looking output speed ... it is quite feasible to suggest the sampling time could have been reduced to provide quicker update rate, but there will is always a practical limit. Remember, if this is being used to measure the speed of a vehicle, then to be useful, it must work over the entire speed range. A car speedometer might produce plenty of pulses at 100 mph, but must also work sensibly at 10 mph, when the number of pulses in a given time will be divided by a factor of 10.

----------

And as a postscript, @robotbuilder's suggestion of measuring the time between pulses is mathematically correct, and in some cases a practical solution. However, with 'cheap mechanical' encoders, I suspect the timing will vary quite widely between adjacent pulses, and you will end up adding averaging filters of some type to get meaningful results. If you watch the scope display, and in particular the timing/frequency readouts, you will see they 'jump around' quite a lot. Once again, you need to try it and see ... sometimes what appears to be the least likely technique gives the best result!

Best wishes, Dave


   
ReplyQuote
robotBuilder
(@robotbuilder)
Noble Member
Joined: 4 years ago
Posts: 2065
 

@electricray1981 

I have forgotten those posts.

speed = distance / time

The distance travelled between pulses is constant let us say it is 0.05 inches.

So to get the speed in inches per second.

Let us say the time between two pulses is 0.1 seconds

speed = 0.05/0.1 

Let us say the time between two pulses is 0.02 seconds

speed = 0.05/0.02

Is that correct?  Math is not my strength.

 

 

 


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Estimable Member
Joined: 11 months ago
Posts: 121
Topic starter  

@davee 

As usul you give such great responses I really appreciate that thumbs up for you. 

Well I want to use these readings for PID control so it needs to be fast but on the other hand as you said there are practical limitation and I will need to tune it clear. If I want to control the speed with these values which will be updated each second I will get a low resonse in the speed controller so I will reduce it nd than check if it all works fine cause making the time too short will result in problems as you mentioned

Grtz,
Ray


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Estimable Member
Joined: 11 months ago
Posts: 121
Topic starter  

@robotbuilder 

I'm a bit lost in your comment.

Speed is indeed distance/time so by having he time between two pulses one can easiliy compute the velocity. 

But in your comment you write here dat the distacne is 0.05 inches, the uC doesnten know this value. It only measures the time between two pulses .... ok great. So next you need to know how many pulses are there to make one revolution. If you know that you can create a algorithm to estimate the speed. 

But comming back to my comment to you and you were right all examples regarding speed detection are based om counting the amount of pulses in a specific time interval. You reduce the amount of code in the inrerrupt with that. Measuring the time between the pulses is mathematically a good way but practically I had so many issues with that that I won do that.

Next I'd like to say (I'm sorry I'm European) don't get offended but working with technical and scietifically subject use the SI units. inches/sec is not a inuitive unit the beauty of SI is that is is all based on base of ten m/s kilograms etc it makes much more sense.

That can be a opinion in relation to what someone thinks is easy to use but when ne starts to crunch the numbers SI is much more easy IMHO 😉

Grtz,
Ray


   
ReplyQuote
robotBuilder
(@robotbuilder)
Noble Member
Joined: 4 years ago
Posts: 2065
 

@electricray1981

The distance between pulses is constant that is all you need to know about that. What that actual value is in cm or inches has to be worked out by measuring the circumference of the wheel and dividing that by the number of slots in the encoder.

It doesn't matter what units of measure you use to measure distance (or anything else for that matter) except when you need others to be able to use that same unit of measure. You can convert between different units of measure by multiply them by a constant.

inches = constant * centimeters
In this case the constant is about 0.393701

Now if you measure distance by counting the pulses that becomes your unit of measure for that particular wheel and encoder. You can use that measure until it comes time to convert that to another wheel diameter and encoder or to units of measure defined for general use like inches or centimeters. All is done by working out the constant required for the conversion.

A unit of measurement is a definite magnitude of a quantity, defined and adopted by convention or by law, that is used as a standard for measurement of the same kind of quantity. Any other quantity of that kind can be expressed as a multiple of the unit of measurement.

Unlike America in Australia we do use SI units because as you wrote it makes more sense (easier to use). My tape measure is marked in both units.

Older folk forget sometimes as I found out when I asked for a pint of milk and the young sales person didn't know what that was 🙂 We now use liters not pints.

The microcomputer doesn't know anything. It is up to you to define it in the program as inches or centimeters.

The reason I used the number of pulses as a measure of distance is because it saved me continually converting everything. It is only when you want to display the measurement do you need to convert pulse count to inches or centimeters.


   
Ron reacted
ReplyQuote
Ron
 Ron
(@zander)
Illustrious Member
Joined: 3 years ago
Posts: 5883
 

@electricray1981 fyi @davee Maybe I am missing something (often the case) but by using micros() between pulses should yield a pretty accurate time for RPM which is then simply converted to MPH by using the known (input from a table) circumference. Sure, lots of math, but nothing complicated. Even if all the calculations were so time-consuming that another interrupt could occur, then simply set a flag in the interrupt, turn off interrupts, then in the mainline detect the flag, do the calculations and reenable interrupts but only set the flag after the second interrupt is detected in order to guarantee you are timing a gap between two slots. Does that make any sense?

Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting


   
ReplyQuote
Ron
 Ron
(@zander)
Illustrious Member
Joined: 3 years ago
Posts: 5883
 

@electricray1981 Actually, the folks who live in the USA use both units, try buying drugs, either prescription or not, in imperial units, and try buying that large bottle of pop in imperial. There is an NDGT video where he lists off a lot more. Of course, all of the sciences use only SI.

In Canada and Mexico, which is also part of America but, more correctly, North America, we Canadians have fallen into the habit of using both partly due to the elephant next door and partly because we can't suddenly start building with non-imperial 2x4's etc. BTW, what do you SI types call a 2x4?

I am 81 and can switch back and forth fairly easily for temperature and length, but other than Kgs, not weight, and other than Liters, not volume. We Canadians also have to deal with 2 volume measurements regarding recipes, Imperial and US. Why they changed that part is a mystery to me. But the bigger mystery is why did the US adopt the measurement system of the country they had just defeated rather than of their ally France a short 18 years later when the French invented the system that became known as the Metric system and ultimately, in 1960, the SI system.

Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting


   
ReplyQuote
(@davee)
Noble Member
Joined: 3 years ago
Posts: 1432
 

Hi Ron @zander,

   Most of your logic about microcontrollers is Ok, but it is ignoring the incoming data quality

Sort of ... "poor data in = poor data out" ... situation.

First of all, imagine you have something like a 'perfect' multi-bladed fan interrupting light, at constant speed, as an encoder mechanism.

If you count how many light flashes you see in a given time, it will be approximately the same for each count, but depending on the phasing of the count window and the motion of the blades, the count will typically vary by 1, or maybe 2, counts.

Now if that is 1 count in a 1000, (0.1% 'error') it probably doesn't but matter, but if it is 1 count in a total of 3, corresponding to 25-33% 'error', then it probably does matter.

-----

In addition, some encoders are far from 'perfect' ... e.g. the cheap rotary encoders that give about 20 pulses per revolution and look something like:

image

Of course, they are made for price, and can do a useful job, but even rotating them by hand shows their 'gritty' nature, so I don't expect 20 pulses per revolution to correspond to transitions at exactly 0, 18, 36, 54.. etc. degrees. 

Hence, if one was rotated at a constant speed, but the transition angles were something like 0, 15, 30, 57,... degrees ('made up' data for illustration, of course), and then the time between adjacent transitions would similarly be wildly misleading as a guide to rotation speed. However, if the time to produce 100 pulses (corresponding to 5 complete rotations) was used to calculate the speed, then it might be within about 1-2% of the correct answer.

I have deliberately picked an encoder that is totally unsuited for speed measurement to illustrate the point, and others will do better, but all will suffer from these limitations to some extent.

Briefly, looking at the 'scope trace on Bill's video, there was some obvious jitter, but this could be due to any number of reasons, including the motor 'gogging' to some extent, limitations in the encoder, and so on.

.........

Does this help to clarify the picture?

Best wishes, Dave


   
ReplyQuote
Ron
 Ron
(@zander)
Illustrious Member
Joined: 3 years ago
Posts: 5883
 

@davee I did understand that, Dave. Your explanation was excellent. I guess I just assumed too much. An error rejection algorithm would be needed, but I assumed that was common knowledge. You could even have another input variable with a high, low, or percentage value to determine what data to keep and what to throw away. The best devices are 1%, good 5%, fair 10% and run-of-the-mill 20%. I don't have the experience to know which is which, so I would create a sketch that just collects the data in an array and, in the end, prints out a simple XY graph. By running that on each new device, I can determine its accuracy and then mark it on the device with a permanent marker or some other way.

I hope I have explained better and am not unconsciously leaving something out. With so many different levels of experience and so many fields of expertise, I am amazed we can communicate at all. I spend half my time daily googling all the various new terms I run across, especially when it is one of your fantastic long detailed explainers. I feel like I am back in school again but this time with Professor Dave!

Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting


   
DaveE reacted
ReplyQuote
Ron
 Ron
(@zander)
Illustrious Member
Joined: 3 years ago
Posts: 5883
 

@davee BTW, I have a device that looks a lot like what is in your picture. Maybe when I leave the hospital next week, I will attempt one of those 'calibration' as I call it, sketches and, with your guidance, maybe even a scope? It's been almost 60 years since I last used a scope, so I am extremely rusty to the point of probably being a total noob. If I can lean on your excellent expertise, I would truly appreciate it. It's one of those Windows-based USB scopes if it matters. I didn't spend much money on one; I doubt I will need it much and certainly can't see a need for any fancy stuff.

Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting


   
ReplyQuote
(@davee)
Noble Member
Joined: 3 years ago
Posts: 1432
 

Hi @electricray1981,

In terms of using encoders, etc, I completely understand why you want to make your system more responsive .. I am no expert on what is available, nor can I offer specific requirements you need to meet your needs, but it seems to be classic engineering compromise situation of trying to figure out which encoder will give you 'good enough' data, without breaking the bank.  I wish you well on your research.

------

As a UK person, who remembers 'Imperial' units from early school days, not only from school teaching, but in terms of everything you could buy, etc. including the ludicrous 'Fahrenheit' temperature scale, plus a currency system with number bases of 12 and 20, so, I can generally handle Imperial units, but since then, not only has the entire scientific world been SI based, but also everyday life in UK now uses metric units ... with a few exceptions, such as those listed below, all of which I will be quite happy to see be brought into the 'modern' world...

  • Road distance signs are in miles, although  footpath distances use kilometres. This means road traffic speed limits are miles/hour (mph)
  • I guess roughly half the population will use feet and inches, plus stones and pounds for their personal height, weight etc.
  • Beer is sold in pints and half-pints ... milk is usually in multiples of a litre ...
  • Some electronic sizing, like 0.1 inch pin spacing ... though of course, that is more of dying legacy size
  • Dealings with the USA ... I am happy to deal with the US, but why does it have to keep living in the past?

So I completely understand why people not forced to use the crazy 'Imperial' system from birth would find it confusing.

Perhaps my favourite is suggesting speed should be specified in 'furlongs per fortnight'

Best wishes, Dave

 


   
ReplyQuote
Ron
 Ron
(@zander)
Illustrious Member
Joined: 3 years ago
Posts: 5883
 

@davee Better known as postal speed, at least here in the Colony.

Perhaps my favourite is suggesting speed should be specified in 'furlongs per fortnight'

Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting


   
DaveE reacted
ReplyQuote
Page 1 / 2