NXT SLAM?

[Helio Perroni Filho]

Hi all,

My course in statistical robotics has been languishing dreadfully for
a while, but now it may finally take off – having a real robot around
has done wonders to my interest in Simultaneous Localization and
Mapping (SLAM) and related techniques (particle filters, EKF, etc).

I wonder if anyone around here has tried to do SLAM on an NXT robot?
For input I'm thinking on sweeping the Ultrasound sensor horizontally,
then taking its readings along with motor positions as polar
coordinates. Is the motor tick counter reliable enough for this? Or
would it slip out of sync over time – demanding the use of a secondary
sensor to calibrate the sweeping movement, e.g. a Light sensor
watching out for a fixed latch? Has anyone experimented with this kind
of design before?

--
Ja ne,
Helio Perroni Filho
http://machineawakening.blogspot.com/

[Marcus Wanner]

On Thu, 2011-01-20 at 23:27 -0200, Helio Perroni Filho wrote:
> My course in statistical robotics has been languishing dreadfully for
> a while, but now it may finally take off – having a real robot around
> has done wonders to my interest in Simultaneous Localization and
> Mapping (SLAM) and related techniques (particle filters, EKF, etc).

Not I.

> I wonder if anyone around here has tried to do SLAM on an NXT robot?
> For input I'm thinking on sweeping the Ultrasound sensor horizontally,
> then taking its readings along with motor positions as polar
> coordinates. Is the motor tick counter reliable enough for this? Or
> would it slip out of sync over time – demanding the use of a secondary
> sensor to calibrate the sweeping movement, e.g. a Light sensor
> watching out for a fixed latch? Has anyone experimented with this kind
> of design before?

The motors don't drift hardly at all in my experience, but you'd have to
use a pretty low gear ratio to get good positioning accuracy with
nxt-python's turn() method (usually gets within 20 degrees unloaded,
according to some exhaustive testing I did while 2.x was in
development). Should work fine other than that and the US sensor not
being horribly reliable or accurate...but that can be mitigated.

Sounds fun and I hope someone else here has some actual experience with
this in nxt-python.

Marcus Wanner

[rhn]

Hey!

Indeed, SLAM was my thesis topic. I didn't sweep the sensor using another motor though, but I rotated the whole robot instead.
I think the motors are good enough for the sweeping. You will get about 10° inaccuracy due to bluetooth/usb delays and mechanical properties, but I highly doubt it will ever get out of sync.
The sonar is completely inaccurate to the point of near uselessness. It has a spread of ~30° and the range can vary depending on the type of surface it hits. I used a long range Infrared sensor to get better accuracy, but then again I didn't do any sweeping, so it didn't do much work :) You would need to use a smart way of adding the data to your map to make this usable (a particle filter could be ok).

For SLAM in general, I extended MRPT for support of the two NXT sensors and added a crappy Python wrapper to it, so you might want to use that library, although I strongly reccommend you use something else ;) The way sensor input is treated, using particle filters actually made the positioning worse than pure odometry.

If you have any specific questions, feel free to ask!

Cheers,
rhn

[Helio Perroni Filho]

On Fri, Jan 21, 2011 at 6:57 AM, rhn <nxpygo...@porcupinefactory.org> wrote:

> Indeed, SLAM was my thesis topic. I didn't sweep the sensor using another
> motor though, but I rotated the whole robot instead.

I thought of something like that, but was afraid the turning axis would lay too far from the robot's center, causing it to move about as it sweeped. Didn't you have any problems with that?

> The sonar is completely inaccurate to the point of near uselessness. It has
> a spread of ~30° and the range can vary depending on the type of surface it
> hits.

Hmmm... I wonder whether we couldn't use machine learning to improve accuracy? Perhaps combining the light sensor to get some sense of the surface type (though I'm sceptical that anything short of an actual camera would do). I do have a Python weightless neural network library in the works; I was meaning to test it on the depth mapping problem that was the basis of my MSc project, but this could prove an interesting warm-up.

> For SLAM in general, I extended MRPT for support of the two NXT sensors and
> added a crappy Python wrapper to it, so you might want to use that library,
> although I strongly reccommend you use something else ;)

Actually I was thinking of using ProbRob. Since it's implemented in Python too, it should be easier to hook it and nxt-python together. I'm also considering implementing the algorithms on my own, since this would be mainly an educational project.

[rhn]

On Fri, 21 Jan 2011 16:16:29 -0200

Helio Perroni Filho <xper...@gmail.com> wrote:

> On Fri, Jan 21, 2011 at 6:57 AM, rhn <nxpygo...@porcupinefactory.org>
> wrote:
>
> > Indeed, SLAM was my thesis topic. I didn't sweep the sensor using another
> > motor though, but I rotated the whole robot instead.
>
> I thought of something like that, but was afraid the turning axis would lay
> too far from the robot's center, causing it to move about as it sweeped.
> Didn't you have any problems with that?
>

I measured the offset from the rotation axis and the position of the sensor was recalculated each time by MRPT. 1cm was not a big difference in distance either because of the sensor accuracy anyway.

> > The sonar is completely inaccurate to the point of near uselessness. It
> has
> > a spread of ~30° and the range can vary depending on the type of surface
> it
> > hits.
>
> Hmmm... I wonder whether we couldn't use machine learning to improve
> accuracy? Perhaps combining the light sensor to get some sense of the
> surface type (though I'm sceptical that anything short of an actual camera
> would do). I do have a Python weightless neural network library in the
> works; I was meaning to test it on the depth mapping problem that was the
> basis of my MSc project, but this could prove an interesting warm-up.
>

If you're thinking about different surface types as the main problem, then coupling the sensors together and using machine learning would help. But the main sources of error for me was angle of the surface (only sensible solution: replace ultrasonic with sth else) and the difficulty of measuring the actual shape of the scanned area. I think the would be solved better by modeling sensor data as probability distribution function, as in typical SLAM. Even if the shape would change or be off, the data would still be good enough to use (but more difficult to navigate).

> > For SLAM in general, I extended MRPT for support of the two NXT sensors
> and
> > added a crappy Python wrapper to it, so you might want to use that
> library,
> > although I strongly reccommend you use something else ;)
>

> Actually I was thinking of using ProbRob <https://launchpad.net/probrob>.

> Since it's implemented in Python too, it should be easier to hook it and
> nxt-python together. I'm also considering implementing the algorithms on my
> own, since this would be mainly an educational project.
>

Good luck :) I hope you do better than me, and manage to find a way to make the sensors actually useful - I'm sure it can be done.

> --
> Ja ne,
> Helio Perroni Filho
> http://machineawakening.blogspot.com/
>

Cheers,
rhn