WebbotLib encoder interpolation

[madsci1016]

Another suggested mode:

For really low resolution encoders, counting ticks may not work well. But measuring time between ticks can fix that problem. Gives really good resolution for low resolution encoders.

I have no use for it, but next time your looking for something to add, it would be my suggestion. (after an ethernet chip of course. webserver on an Axon would be cool, and so would an Axon that could Tweat)

[Admin]

For really low resolution encoders, counting ticks may not work well. But measuring time between ticks can fix that problem. Gives really good resolution for low resolution encoders.

See above where I said:

Actually, if coded, it can get even fancier by accounting for rotational velocity and guessing the location between clicks.

This method works fairly well, as long as the rotational velocity is predictable. If acceleration occurs and you don't model it, the method just whacks out, causing dogs to eat kittens and stuff like that.
 

[madsci1016]

I didn't understand what you mean by 'guessing' the location of clicks.

Can it be much more difficult then using a timer and just pulling out the current count value every time the pin changes? If the timer overflows then assume the rotation has stopped.

[Admin]

I didn't understand what you mean by 'guessing' the location of clicks.

Can it be much more difficult then using a timer and just pulling out the current count value every time the pin changes? If the timer overflows then assume the rotation has stopped.

The basic equation is:

fraction = time_passed_since_last_click / total_time_passed_for_last_click
total_click_count = sum_count + fraction

But fraction must be less than one and account for rotation direction.

And what about the case when velocity dramatically drops between clicks - thats when it whacks out. If your robot doesn't have accelerometers, you are in effect 'guessing' the fraction between clicks.

And Webbot was against pulling in a float library to do this . . .

[Webbot]

So you are basically using interpolation

ie if the recent history says 1 click every 10 seconds (ludicrous I know - but just to keep the example simple)
and 5 seconds has gone by since the last tick then we could assume another half tick on the encoder.

[madsci1016]

I think I get the gist of it, but let me try this. My thoughts don't involve float.

I'm going to scale some things for low encoders.

On my SAGAR robot, i'm concerned about two things, maintaining a certain speed and recording how far i've traveled. The resolution of distance traveled can be as good as the distance traveled by my wheel in-between encoder clicks. Let's say i get 8 encoder clicks per wheel rotation. So that's as good as I can get for distance traveled resolution.

However, the problem is my PID controller trying to maintain a certain speed needs a good input resolution. at only 8 click per rotation and speeds of 1 rev/second, thats a horrible input for any PID controller. If the PID frequency is 2Hz, that means it's somewhere between 0-4 clicks of resolution (~3 bits) to work with.  However, if the input of the PID was the time of a click duration, it would be as good resolution as the timer used. So now I can get 8 bit (or 16 bit depending on the timer) resolution to give my PID controller and have a variable PID controller rate up to 8 Hz at full speed.

This would work well for maintaining speed using a low count encoder.

[Webbot]

But what happens if the wheel is moving so slowly that the timer overflows when measuring a tick (or if the motor stops)?
I think that both ideas are actually the same thing - you are measuring current speed by the length of the last tick whereas admin is doing it by the time between ticks.

@Admin - It would be good to split this into a separate topic as its now more 'theoretical' rather than WebbotLib encoder specific.

[madsci1016]

But what happens if the wheel is moving so slowly that the timer overflows when measuring a tick (or if the motor stops)?

If the timer overflows then assume the rotation has stopped.

But my method does avoid float, so would it be practical to add to the lib?

[Admin]

note: topic split from WebbotLib thread

[Webbot]

Ok - so how about this as a generic solution.
Lets assume the motor is turning at a fixed speed and the encoder ticks are coming in at every 100 of the timer counter ie 0, 100, 200, 300, 400 etc
If I store the timer counter for the last tick then I can detect that the difference from the last tick to the new tick is always 100.

If I add a new routine called 'getFraction' or similar then it can do:
numerator = (current_timer_counter - timer_counter_at_last_tick)  - ie the time since the last tick happened
denominator = 100 (ie the time between the last two ticks).

These are just integers - not floats.

To calculate the fractional distance then divide the circumference of the wheel by the 8 ticks you get per revolution (ie distance for one tick)
The fractional distance is then: (distance for one tick) * numerator / denominator

Since I'm only returning the numerator and denominator integers then no float is involved. However if you choose to use it when calculating the fractional distance then thats up to you.


Does that help everyone?

[Admin]

Well, my original suggestion in my emails was to make it as a separate feature that can be added on to the current encoder devices called 'use encoder interpolation?'

Then a note on the side will say "This feature uses interpolation to estimate the encoder position given a known rotational velocity. It is only an estimate, as it assumes a near-constant rotational velocity, but can otherwise greatly enhance encoder resolution by an order of magnitude. Please note this feature requires floating point libraries, a problem for lower memory mcu's."

or something like that . . .

[madsci1016]

I think it's perfect Webbot. For PID speed control I would just use the numerator, and for calculating fractional distances you can use both.

[waltr]

This method of counting the time between wheel encoder ticks is exactly what I use to maintain wheel speed. I developed this method some years ago with low resolution wheel encoders that had 8 positions. I did post my code some time ago (earlier this year) that showed how its done on a PIC, C code. This method does work extremely well.

If the Bot is going very slow or if it gets stuck and the wheels don't rotate then the counter does overflow and a flag is set (this happens in a hardware timer ISR). The main code checks for the flag and commands a different movement strategy if the wheel speed should be faster. There is another flag that is set when the wheel speed should be slow like when stopped or for a few PWM cycles during acceleration that inhibits the setting the the encoder count overflow flag.

Here is the link to the thread with my code:
http://www.societyofrobots.com/robotforum/index.php?topic=11042.0