Supports measurement of encoders in ticks.
All reading from this library are in 'ticks'.
What do they do? They measure the clockwise and counter-clockwise rotation of an axle. For our purposes they are normally mounted onto motors or wheels. Each encoder emits a given number of 'ticks' per revolution with the ticks increasing if the axle is turned one way and decreased if turning the other way. If we know how many ticks the angle has moved, and the number of ticks the encoder produced per 360 degrees, then we can work out how many degrees the axle has turned. Then, by knowing the wheel circumference, we can convert this into a distance. But beware of slippage: if the robot is on ice, or a steep hill, then the wheel may turn and generate the ticks but the robot may not have moved. Slippage can be minimised by changing acceleration gradually (ie avoid wheel spin unlike those drag racing cars!), by having 'gripping' wheels etc etc.
There are other uses for encoders - including non-robot stuff. I bet you've had one of those old scratchy radios where every time you twiddle the volume you hear a horrible scratching noise. That is because they use a potentiometer and that noise is caused because it involves mechanical contacts. More modern designs use encoders for volume control as there is no mechanical contact - so less noise and nothing to 'wear out'.
Since all of the devices have been implemented in the same way then it means that you can swap one device for another by only changing the #include and the MAKE command used to create the device.
So here is the generic way to work with a <DEVICE> of a given <MAKE> and <MODEL>:-
// Include the relevant sensor file
// Create the device
<DEVICE> myEncoder = MAKE_<DEVICE>(....);
In your appInitHardware you should initialise the device:-
Then in your main loop you can read the sensor using:-
The value can then be read independently into a variable of type 'ENCODER_TYPE':-
ENCODER_TYPE ticks = myEncoder.encoder.value;
Or dumped to the current rprintf destination using:-
As of WebbotLib Version 1.25 the encoderRead function can, if 'interpolation' is enabled, return two additional pieces of information which, as per the example above, can be accessed using:-
TICK_COUNT t1 = myEncoder.encoder.timeSinceLastTick;
TICK_COUNT t2 = myEncoder.encoder.durationOfLastTick;
The 'timeSinceLastTick' is the number of µS since we last a received a tick; and durationOfLastTick is the number of µS between the previous two ticks.
This means that, as a rough approximation, the 'durationOfLastTick' can be used to guess the current speed of the motor. ie if it has a value of 1000µS and the encoder is giving 200 ticks per revolution. Then a full revolution would currently require 1000 x 200 = 200,000µS = 0.2 seconds. Hence the motor is rotating at 300 rpm. Given that we know the wheel circumference then we can turn this into a ground speed.
Obviously this assumes that the motor speed is fairly constant as it is just calculated from the last 'tick'.
The 'timeSinceLastTick' is useful if your encoder only has a small number of stripes but the wheel circumference is quite high. In this case a single 'tick' can represent a significant distance. So this parameter allows you to estimate the current fraction of a tick.
For example: if 'durationOfLastTick' is 1000µS and the 'timeSinceLastTick' is 500µS then we can estimate that the wheel has turned by a further 0.5 of a 'tick'.
The 'interpolation' can be turned on and off via the MAKE command and also at runtime by setting the 'myEncoder.encoder.interpolate' variable to either TRUE or FALSE.
When interpolation is turned on then there is extra processing required for each tick and so the maximum number of ticks per second is reduced (see later for metrics). However: since interpolation is only generally useful for low resolution encoders then this should not be an issue.