Drive motor and encoder.

[roontoon]

My question is does the current software support both magnetic and optical encoders for the odometer feature of the software.

d

 

[nero76]

@Daniel: Both types of encoders should work as they use the same signal:
http://www.ardumower.de/images/ardumower_odometry_encoder.jpg
When driving forward, odometry counter should increase, when driving reverse, odometry counter should decrease (counter shown in Ardumower console or pfodApp).

 

[roontoon]

I wanted to be sure as I will be buying drive motors soon, The motors that I am looking at have a built-in magnetic encoder. They also have an optical encoder but only has an add on not pre-installed on a motor. Will the new code be able to use the odometer from the motors to create a fairly accurate map of your lawn? If so will that data be converted to an array for us to use as a map? Thanks!

 

[nero76]

@Daniel:

Long answer:
The map is already created (you can see it via pfodApp->plots), however it's not accurate - That's because odometry drifts heavy over time (think of a counter that counts +5% or -%5 all the time).

The actual robot position has to be corrected and that is something we'll work on soon. The trick is:
1. To reduce the error by combining more sensors (odometry, gyro, compass, gps etc.) - that's typically done using a 'Kalman' filter (TODO).

2. To correct the position using known places (e.g. perimeter hit). But that requires an exact map of the perimeter. Typically point 1 and point 2 is a iterative process (again: Kalman helps here).

Short answer: it's something we should work on soon ;-)

Btw: Latest SVN versions already use odometry to let the robot drive straight when in forward driving state.