The built in Northstar system for the Rovio allows us to track the current position of the robot in real time using IR room beacons.  When I started the Automated Mapping System for my Home AI I ran into a few issues, mainly that as the Rovio gets further from a beacon the positional data became less reliable.  I realize this is to be expected but it makes mapping the robot dataset to a real-world view of the home a bit difficult.  That is when I realized I don’t need the robot to see the world the way I see it, I need it do see the world in a consistent manner.  Even if I perceive the dataset to be flawed, the robot sees it as perfectly valid data time and time again. 

With this in mind I redesigned my internal use of the data and cleared the position database.  In my prior version I was only storing clear and blocked paths in front of the robot but I have now expanded the database to store Known Clear, Assumed Clear, and Blocked locations which are displayed in Green, Yellow, and Red on the control panel.  I am assuming that the calculated x, y position of the Rovio is free of obstacles (since we’re sitting there), and that the sensor data is coming from 6″ in front of the Rovio.  While the Rovio will report an obstacle at a much greater distance I can handle that when the Rovio revisits that location at a different angle, so even though my data is not perfect at the start it only takes a few passes before things start filling in.

A quick scan of the Rovio API Documentation tells me that the x, y positions are between -32767 and 32768 so I assume that 0, 0 is directly centered under the beacon on the ceiling.  Browsing an older thread on RoboCommunity my assumptions were proven to be correct as you can see in this graphic created by milw.

Now that I knew exactly how the positional data worked calculating a point in front of the Rovio was as easy as some simple math.

            double offsetx, offsety;

            offsetx = x + (distance * Math.Sin(theta));
            offsety = y + (distance * Math.Cos(theta));

After running some quick tests I realized that the base y coordinate was backwards for some reason.  I am not sure if this is due to something I did, but a quick fix was implemented.

            y *= -1;

I increased the size of my brushes and ran another few laps around the computer room to verify the changes and everything looks perfect.  Well, almost.  It seems I was a bit too generous with my distance factor for the obstacle sensor.  You can see the problem in the following image, represented by the large patches of “assumed clear” sections between the “known clear” and “known blocked” areas.

Now that I know the mapping is working properly, I can unleash both of the robots tonight in the basement.  Hopefully my “disable mapping and go home” logic works when the battery runs low, guess we’ll find out.