[sensors] Added an 'encoders' level to the velocity sensor

[severin-lemaignan]

This new abstraction level for the velocity sensor that returns encoder ticks instead of linear/angluar speeds

It assumes a differential drive robot as accordingly adds properties to setup wheel radius, wheel base (and encoder resolution).

The current behaviour (linear + angluar speed) is now the (default) 'standard' level.

This pull-request is not ready for merge. I would like first to get feedback on:

• general usefulness (beyond my own needs :-) )
• is it a good idea to have it as an abstraction level of the velocity sensor? (maybe not, but it fundamentally returns the same information as linear/angular velocities, at a lower level of abstraction...)
• I'm a bit lost between local and world velocities, and I'm not sure I got it correctly (let say, I'm pretty sure I didn't...)

[adegroote]

I'm not sure to see the relation of velocity, for me, it looks like really low-level odometry sensor.

add_propery() lines are too long. wheel_base and wheel_radius should probably be robot property, not sensor property. It may be nice also to be able to extend to caterpillars

[adegroote]

Also, it would be nice to be able to test at builder time that the sensor is configured properly for an 'differential robot', not a 'standard one'.

[severin-lemaignan]

@adegroote Indeed, Odometry is a better place (I started there, then I switched to Velocity... I do not remember why...). Updated accordingly the PR.
While here, added a unit-test (do not pass on my computer :-( precision issue? rounding error? feedback welcome).

add_property lines wrapped.

For the wheel_radius and wheel_base, I agree that those should be managed at the robot level. This would likely require first the creation of the DifferentialDriveRobot parent class. I can create a separate issue for this if you wish.

[adegroote]

The comment speaks about dtheta, while the code use dw, it is a bit confusing.

Considering the unit-test, I think there is several issues. The precision is probably not really good per se, as you basically add a lots of small float. On the other side, the unit-test use a fixed DELTA, while the error definitively increase at each "step". If you want to keep a fixed DELTA, you should probably store last_{left, right}_encoder and compare with them.

Concerning DifferentialDriveRobot, PhysicalWheelRobot contains most of the needed logic (if not all).