UvA Rescue Team 2007 - Bayu Slamet's Log

Log Tijn Schmits | Log Arnoud Visser | League Results Page | League Main Page | League Rules 2007 (PDF)

Curriculum Vitae of Bayu Slamet

2008 - present: Project Architect e-Business at KLM Information Services.
2003 - 2007: Freelance Software Engineer, I have been responsible for the successful realization of several software engineering projects on a freelance basis.
2000 - 2007: 7 years of working experience as part-time IT professional, last position: Software Architect at Logic Rules IT.
2000 - 2007: MSc in Artificial Intelligence, graduated with Honors. Won 2 awards at the international RoboCup Rescue Championships of 2006 and (co-)authored several publications.

Publications in Robotics Research

Arnoud Visser and Bayu A. Slamet: 'Including communication success in the estimation of information gain for multi-robot exploration'. In Proceedings of the 6th International Symposium on Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks (WiOpt), IEEE Publishing, ISBN 978-963-9799-18-9. Berlin, Germany, June 1, 2008. [PDF 2.69M]
Arnoud Visser and Bayu A. Slamet: 'Balancing the information gain against the movement cost for multi-robot frontier exploration'. In the European Robotics Symposium (EUROS), Springer Tracts in Advanced Robotics, volume 44, pages 43-52, Springer-Verlag. Berlin / Heidelberg, Germany, February 12, 2008. [PDF 761K]
Arnoud Visser, Bayu Slamet, Tijn Schmits, Luis A. Gonzalez Jaime and Aksel Ethembabaoglu: 'Design decisions of the UvA Rescue 2007 Team on the Challenges of the Virtual Robot Competition'. In Proceedings of the Fourth International Workshop on Synthetic Simulation and Robotics to Mitigate Earthquake Disaster (SSRMED). Atlanta (GA), USA, July 2007. [PDF 1.40M]
Max Pfingsthorn, Bayu Slamet and Arnoud Visser: 'A Scalable Hybrid Multi-Robot SLAM Method for Highly Detailed Maps'. In Proceedings of the 11th RoboCup International Symposium. Atlanta (GA), USA, July 2007. [PDF 1.76M]
Bayu Slamet and Max Pfingsthorn: 'ManifoldSLAM: a Multi-Agent Simultaneous Localization and Mapping System for the RoboCup Rescue Virtual Robots Competition', Master’s thesis, Universiteit van Amsterdam. Amsterdam, The Netherlands, December 2006. [PDF 9.34M]
Bayu Slamet and Arnoud Visser: 'Purposeful perception by attention-steered robots'. In Proceedings of the 17th Belgium-Netherlands Conference on Artificial Intelligence (BNAIC). Brussels, Belgium, October 2005. [PDF 157K]

RoboCup Rescue World Championships 2007, Atlanta (GA), USA - Virtual Robots League

UvA Rescue Team Results:

July 2 - Mobility Test: passed
July 3 - Mapping Test: passed
Scores reset for prelims.
July 4 - Preliminary 1: 6th (6th overall)
July 5 - Preliminary 2: 3rd (4th overall)
July 6 - Preliminary 3: 3rd (3rd overall)
Scores reset for semis.
July 7 - Semi-final 1: 4th (4th overall)
July 7 - Semi-final 2: 3rd (3rd overall)
Scores reset for battle for 3rd place.
July 8 - Battle for 3rd: lost. :-S
Overall Result: 4th place!

Mapping and Exploration Results

Blue = unexplored area, White = explored area, Green = explored area that is cleared of victims, Black = detected obstacles (walls. furniture, debris, etc.)
Indoor area, 2 robots, 276 m². This very high quality map was acquired in the 3rd preliminary. We deployed 2 Pioneers that each explored a different part of the building. Their findings have been communicated to our Operator through the simulated Wireless Communication Server which only has limited band-width.
Indoor area, 4 robots, 283 m². This is the map we delivered for the first round of the semis. It demonstrates the scalability of our system to 4 robots and also the robustness of our mapping algorithm that is able to successfully merge the findings of 4 robots into a single high quality map.
Outdoor area, 4 robots, 1431 m². This seemingly less quality map covers about 5 times the amount of area as we had until now. Our robots were able to explore this much area by making effective use of their communication capabilities. The robots that got furthest lost contact with the base-station due to the limited range of the wireless network. However, our system is capable to reach beyond this limitatoin by using robots as intermediate 'hubs'.

Features

Accurate and highly detailed maps
Scalability to teams of multiple robots
Efficient autonomous frontier-based exploration
Team-level coordination of rescue site coverage efforts
Robust to limited band-width and partial connectivity communication scenarios
Obstacle avoidance based on 'safety maps'
Supports several state-of-the-art scan matchers: IDC, WSM and MbICP
Boosting framework based on quad trees for significantly more robust scan matching by IDC and WSM

August 16, 2007

Done! :-)
The research conducted over the last months has been a fantastic experience and has resulted in two paper submissions. A paper on 'Multi-Robot Rescue Site Coverage using Manifold Maps' was sent for review to a special issue on multi-robot exploration of the AMAI and another paper on 'Boosting Iterative Closest Point Scan Matching using Quad Trees' will be submitted to ICRA.
Many thanks go out to Arnoud Visser under whose excellent supervision I have been able to acquire these results, to Max Pfingsthorn from Jacob's University for many helpful discussions and insights, and to my fellow members of the UvA Rescue Team: Tijn Schmits, Luis Gonzalez and Aksel Ethembabaoglu.
The completion of these papers mark a significant milestone for me: they close the final projects for my Master of Science (!). I am really happy ... of course .... but my mind seems to have a bit difficulty to catch up with reality ;-p. But I guess that will come soon enough though, I am sure the champagne will make my mind run smoother ;-).

August 15, 2007

Looked up the map we acquired in our best indoors exploration effort from 2006:

August 13-14, 2007

Exploration experiments ....... it took some time, but it's worth it. Each set compares a single robot with a team of 2 robots.
Starting in the north-east corner (415 vs 518 m^2):
Starting in the north-west corner (378 vs 637 m^2):
Starting in the lobby (498 vs 707 m^2):
This very arena was used during prelimaries 2 and 3 and in the semi-finals in 2006. Back then we achieved 104 m^2 (8 robots), 120 m^2 (7 robots), 262 m^2 (6 robots) respectively.
The best run by any team was by Freiburg: 579 m^2 (8 robots).
Basically, the single-robot results would have placed us among the best explorers already. With 2 robots we cover more area than any team did back then (starting from the lobby).

August 12, 2007

Back to programming.
Value iteration to acquire the safety map takes too long. So I implemented an approximation that applies a Gaussian convolution kernel to the occupancy grid. This is what the Gaussian-blurred approximation looks like:
Paths planned on this approximation will not be optimally safe as when they are planned on the safety map acquired by value iteration, but that's not a problem as the paths will be planned far enough from the walls none-the-less.
Here a test run of an exploring robot that used the Gaussian approximation, note how it has no trouble at all to get through the narrow corridors:
Interestingly: the robot moves much more efficient on the paths from the Gaussian map than on the paths from the safety map. This is because the optimally safe paths involve many twists and turns that are the consequence from every single irregularity in the walls. The paths on the Gaussian map on the other hand are mostly straight lines.
Multi-robot exploration is starting to work! Just see how they nicely split up the work (unfortunately Achilles fell on its back near the end, but that's a detail ;-p):
Did a single-robot experiment and multi-robot experiment from the same start positions. Below the exploration paths:
And here are the corresponding charts that plot the amount of explored area in square meters over time:
The single robot results are quite good already. The slope of the plot declines a bit when the robot enters rooms, which makes sense of course.
The two robots manage to cover the same amount of area in approx. 12 minutes, but only explore 25% more in the end. This is primarily caused by the huge redundancy in the trajectories.
Also ran some earlier tests where the robots start from the Lobby at the bottom, then the explored area scales more significantly but unfortunately I didn't have my area measurement tracking in place yet during that run.

August 10-11, 2007

Writing, wirting, writing .....
Got my bearings on the AMAI paper. It is approximately 30% done.
Got ICRA paper almost done (90%).

August 9, 2007

No progress on the coding front today.
Started the AMAI paper. We have 10 pages of crap now, tomorrow's target is to turn this into quality content.
Arnoud got Luis set up with the current code, which is great news. He is confirming the robustness of our frontier exploration strategy in various environments now.

August 8, 2007

Path planning works too. Based on the 'navigation map' which indicates safe ways to go (avoiding obstacles) paths can be planned to arbitrary locations. The path planner is based on the well-known A* search algorithm.
On the left the map used as input, on the right the planned path (red dots) from the origin to the largest frontier found:
Computing the safety map is based on value iteration where the obstacles are propagated through the free space. This can take quite some time, especially for larger maps. Just extracting the free space on the other hand is super fast. Below, all the path plans to all frontiers are plotted, this time the plans were based on the free space:
This took less than a second to compute on my laptop. The paths are not as good as those based on the safety map of course, note how the red lines get dangerously close to the walls. However, reactive behavior that avoids obstacles when executing the planned path should be able to deal with this. The additional benefit is that multi-robot exploration where robot's form dynamic obstacles to each other is also accounted for.
Single-robot frontier exploration works! This is what a single robot acquired after 20 mins of exploration. The robot just followed the path indicated by the safety map, no explicit obstacle avoidance has been implemented (yet):
The robot started in the garage in the upper-left, went to the upper-right and then managed to get out of the garage through the doorway. First it turns left, to the wide corridor on the right but quickly thereafter it decides to go back and take the other corridor. After that it goes up and down several narrow corridors until it takes the one on the far left that takes him down. Along the way the robot detected 2 victims (middle-left and bottom-left).
The current utility function to valuate frontier regions is simply area / distance. This explains why the robot does not really pursue corridors and is a bit greedy to get to open spaces.
Put quite some effort in improving the robustness and performance of frontier exploration. The safety maps are now computed much faster than before and also the path-following behavior is robust to quite some error in the map:
The robot started in the center, then first explored the bottom right corner with the 4 pillars where it also found a victim. Then it headed to the left and up where it found another 2 victims. When done at the upper part it decides to go all the way back through the tunnel on the far left to return to the center again. It is heading up on the right when it runs out of batteries. Note: it would have been much smarter to continue exploration in the upper part, but this frontier was ignored as it yielded too few information gain (threshold will be adjusted/removed).

August 7, 2007

Got another important frontier extraction tool to work: the estimation of the expected information gain for each frontier region.
Below all regions that are beyond the frontier lines have been colored. The blue flags indicate the estimated center of each frontier and in white text the size of each frontier is plotted:
Note that in fact ALL frontiers are found, even those that have only an area of 1 pixels. The visualization only renders the frontiers larger than 1 squared meter (= area of at least 100 pixels).
The extraction of this frontier information is superfast; takes less than a second for the whole map on my laptop.
My current thought is that this tool combined with the navigation map are all that is needed for efficient exploration. The extraction of the frontier lines that I implemented yesterday is perhaps obsolete already. The next step is now to implement greedy single-agent frontier-based exploration.

August 6, 2007

Got most of my desired frontier extraction tools to work.
The extracted features are based on the map below. On the left the occupancy information and on the right the associated safe area (in gray):
Then this is what frontier extraction returns (gray = safe, black = no go, white is frontiers):
And this is the 'navigation map', acquired after propagating the obstacle data through the safe area using value iteration:
So, now the robot's know where they should go and which are the safest ways to navigate there. What remains is a (straight-forward) implementation of A* to plan paths based on all this and subsequently a behavior needs to be designed that leverages all these tools to actually have the robots perform frontier exloration.

August 2, 2007

Quantitative analysis day ...
Made some modifications to the scan matching code such that it outputs all relevant measures to Visual Studio's Immediate window.
Collected measurements for WSM, Q*-WSM, IDC and Q*-IDC on the 'The Park' dataset.
Interesting! We already had numerous visual proofs that the Q* (quad tree based) variants had a lot to offer, the numbers clearly underscore this.
Q*-based scan matchers find more useful correspondencies which leads to a tighter match with significantly less residual uncertainty and are better able to avoid local optima. So the Q* framework yields a significantly more robust and accurate scan matcher.
BTW: in the morning I had a go at the famous Victoria Park dataset from the Australian Centre for Field Robotics (Sydney), but this one comes in such an awkward format that a special parser needs to be written to be able to process it. Future work ...

August 1, 2007

Spent the last couple of days getting all recent scan matching results compiled into a paper.
Also made a start with research into exploration under restricted communication ranges.

July 25, 2007

Arnoud got even a better result on the CMU Newell Simon Hall:

July 24, 2007

Started ICRA 2008 paper. Got all the formatting rules to work for me, which took some effort.
After I formulated my outline, some initial texts and (mostly) images in I already had 3 pages. Considering the page limit of 6 pages I am 'half-way done' already! ;-p,
Spent the evening processing some datasets from Radish. The results astonished me. On the left you will see a sample of what the map 'should' look like, on the right the result I acquired with QuadTree-based WSM:
The befamed AP Hill dataset:
CMU Newell Simon Hall:
Intel Lab Oregon:
MIT CSAIL building:
This is beyond imagination! All of these datasets by themselves are supposed to pose a challenge, and our system processes them as if it is all peanuts. Especially the AP Hill log worked out beautifully, considering that the robot really went all over the map several times. Some of the rooms have been visited 5 times or perhaps even more. CMU's Newell Simon Hall only had one loop, which was closed implicitly. The Intel Lab Oregon had 2 loops, initially SLAM is about to overshoot, but then it self-corrects and continuous beautifully. The MIT CSAIL building was tough, long straight corridors mostly, with plenty chance to accumulate error. Going up and down a single corridor posed no problem, some of the loops early in the log neither. The robot even manages to go back from th top towards the middle-right without loosing track of the map. After that it enters a room on the right and things get worse, so I stopped the run.
Edmonton Convention Centre:
This logfile covers a very large area, yet it is on this logfile that we probably produce our best result so far. Several loops were closed implicitly, all without even the slightest glitch. Our map is more detailed (resolution of 2cm/pix) than the original one (10cm/pix). Also, the max-range I used (20m) appears to be a bit on the low side, in the original map the laser beams go further. This is most obvious in the upper-right with the right outer wall, where our system could have connected two walls but didn't since they did not coincide (the laser did not reach far enough to make the walls extend that far).
Stanford Gates:
That was the last one for today. Stanford Gates is a huge logfile (~200MB) which involves a run over several hundreds of meters. The robot starts at the bottom and makes a 'small' loop over the nearest 'bridge' that connects the left and right corridors. So far the map looks razor-sharp. After this the robot makes a larger loop by moving entirely to the top and then back to the bottom, at this point some aliasing occurs. Then the robot takes a long time to inspect all the details of the 'bridge' in the middle (the one traversed in the first loop) and only after a while it will traverse the loop on the upper left. This last loop was not entirely closed, the patches that should've matched were ~1.5m amiss. The logfile involved over 15K scans which resulted in approximately 3000 patches. The QuadTree handled all this just fine. Only at the bridge I noticed that things started to slow down significantly, apparently the QuadTree was holding so much information there that the overhead had grown to reasonable proportions.

July 24, 2007

Extracted the most challenging loop from the Intel logfile available on Radish:

Incremental WSM (left) vs QuadWSM (right):

Incremental IDC (left) vs QuadIDC (right):

While IDC has a LOT to gain by QuadTrees, WSM only seems to suffer. A close inspection reveals what happens: WSM (too) eagerly attempts to match walls of neighbouring rooms.

Note that in the bottom-left corner, QuadWSM detects that it is overshooting and that some 'self-correction' takes place.

July 23, 2007

Results on the tape-loop logfile are much better now. From left to right you see the raw data, the result obtained by QuadIDC and then the result from QuadWSM:

This is what regular (incremental) IDC (left) and WSM (right) make of the same logfile:

In 'The Park' results are equally impressive. Below a comparison of WSM (left) vs QuadWSM (right):

And of course for IDC (left) vs QuadIDC (right):

July 22, 2007

Got the QuadTree on the global level to work. All the points that are in the manifold are now indexed by a QuadTree for fast nearest neighbour lookups that search the entire map.
It was easiest to make a modification of IDC that takes advantage of this global index. The results below were acquired by having IDC match every new scan against the whole manifold, from left to right you see QuadIDC based on INS, QuadIDC based on Odometry and the original 'incremental' implementation of IDC:
Clearly more tuning is in order since the quad-tree based version is too sensitive to distractor points. So, on the global level the old version yields the best result, but also note that on the detail level the quad-tree based version yields much sharper walls and other obstacles. So, the correspondence error reduces but the risk for false correspondencies increases.
A funny thing to observe in the left-most image is that some self-correction occurs. At the bottom IDC mis-matched one scan (both rotation and translation) but later on it undid the rotational error it introduced. The translational error remained.
On another note: the quad-tree based version was still done with the logfile in 3 minutes. The original version takes approx. 7 minutes.
Got an early version of QuadWSM up and running too. It seems to work, but I think there are still some bugs. The maps show too many errors and also it takes too long (to many iterations). Below are the preliminary results. from left to right you see QuadWSM based on INS, QuadWSM based on Odometry and the original 'incremental' implementation of WSM:
Did some more testing with QuadWSM, and found out that there is no bug. All is just perfectly fine, the mis-matches were simply due to an under-tuned scan matcher. Below on the left you see the map just after a mis-match occurs, clearly the remainder looks fine, but here QuadWSM got stuck in a local optimum. After reducing the maximum distance over which correlations may be found I got the map on the right with the exact same code:
Note that by matching a scan against the entire map, loop-closing has become an implicit operation. Near the end of the robot's trail you see this happening twice. The passage-way towards the right is identified correctly and a loop was closed. But just several meters below the two top-down walls are also found to be correlated, and this time the identification is wrong. The walls should actually be two separate ones just several cm's apart. It really is a minor error, the only reason it is even visible is because all the rest of the map is so accurate.

July 21, 2007

Implemented a QuadTree that is able index points in 2D. The implementation is focused on nearest- neighbour searches in 2D.
Implemented a sub-class of the WSM that uses a new point-correlation strategy based on QuadTrees, and the results are amazing. All I do is putting all the points in a QuadTree and use that to find nearest neighbours instead of computing the full distance matrix over which I have to loop to find nearest neighbours. The performance increased by a factor of 2.
Computing the full distance matrix requires 181*181 distance computations and comparisons. In the QuadTree I only store 5 points per Cell. There is some administrative overhead in the tree of course, but when I found the cell that contains my potential nearest neighbour I only need to check that cell and all cells that border on it. In a perfectly balanced QuadTree this results in 9 cells to search through which leads to 181*9*5 comparisons. Significantly less.
Sometimes there are fewer cells and sometimes there are more, but using numerous little tricks performance is rather good. Even in my current naive implementation where I construct the full QuadTree index for every point-correlation stage (which happens once per scan match iteration) performance is boosted by a factor of 2.
The next step is keep a QuadTree on the manifold level and to use that to find correlations. The consequence would be that every new scan is matched against the entire map. This has the same effect as local submaps, but then on a larger scale and potentially with more effect.
As soon as it works I hope to see significant improvements on some of the logfiles I have been running the last couple of days.

July 20, 2007

Continued yesterday's work on analyzing logfiles from Radish and other sources.
Meanwhile I spent a lot of time helping Luis getting up-to-date with all the recent code changes.
By the end of the day I still had not found a good logfile to use. After another day of fruitless logfile processing I have to change plans.
Did some research on QuadTrees. Maybe I can implement a smart local-submap mechanism that can use large parts of the map while still being performant. This looks promising.

July 19, 2007

Enhanced LogDriver so that it can merge the INS readings with the Hokuyo readings that are stored in separate files. Below a screencap of the map acquired by dead-reckoning on the INS:
Spent the rest of the day trying out different logfiles with real-world sensor data with different scan matchers and slam settings.

July 18, 2007

Today is all about my search for a mostly challenging logfile.
Arnoud found several. Apparently Olaf and some people have been recording a logfile using a Hokuyo mounted on a Nomad robot. The nice thing is that they screwed the Nomad's odometry with some duct-tape attached to one of its wheels. Add to this the limited range of the Hokuyo and we found ourselves a challenge.
And yes, it is a challenge indeed, this is what WSM makes of it:
Also did some further testing with the MultiICP scanmatcher in The Park. It seems that it may be beneficial to have IDC take over as soon as the covariances of WSM are beyond 50cm for the translational elements in the trace.
When using initial estimates from INS (left = MultiICP, right = WSM):
When using no initial estimates (left = MultiICP, right = WSM):
This clearly shows the benefit of using IDC as a fall-back option. All that remains now is to validate these results on real data.
Did numerous tests on the Hokuyo log found by Arnoud earlier today, but haven't been able to get an acceptable map without using odometry. Meanwhile Arnoud got the odometry data too, so later we can investigate if this yields better results.

July 17, 2007

Implemented a 'Multi-ICP' scan matcher. It is primarily based on WSM, but uses IDC as a fall-back option when WSM does not converge to an estimate with enough confidence.
This MultiICP yields a significantly better result on the logfile from 'The Park':
Also ran it on the map from the second preliminary, where the Pioneer first bumps into a car and then into a victim. The original map showed quite some misalignment as a consequence of these bumps. With MultiICP this misalignment seems to remain:
In the park IDC took over in 27 of the 798 scans, in the 2nd preliminary IDC was used only 3 times.

July 16, 2007

In an attempt to find out which scan matcher 'breaks down' first as the scans get sparser I ran the logfile from 'The Park' with a maxrange of 16 meters (instead of 20 meters):

July 15, 2007

Continued working on frontier extraction. Using AForge.NET I have been able to get some initial extraction methodology to work. On the left-side the current map that was used as input to the frontier extraction routine, on the right side the white regions mark the frontiers extracted:
The trick is to apply some image processing filters that 'clean out' most of the noise. For example, the input map above was based on raw INS readings (dead-reckoning), hence it contained lots of disconnected black dots (noise). Using a sequence of appropriate filters all this can be get rid of, resulting in the solid white frontier-regions.
Later this day I actually managed to extract the frontiers, i.e. those positions where safe-space borders on unknown space combined with those positions where safe-space borders on interesting-space (which is the known free-space that is outside the safe-space).
The funny thing is though that wall extraction is not too precise yet: given noisy data the walls are ghosting too much and false frontiers are detected. But when provided with clean data (i.e. after WSM processed it) the walls are too thin, and are not found as bordering on the safe-space. Which causes frontiers to be found just between the wall and the safe-space ..... will have another look tomorrow.

July 14, 2007

Found a paper by Ye and Borenstein who have done extensive experiments with the SICK LMS 200 to determine all the characteristics. One thing they found is that for ranges between approximately 2 and 2.5 meters the standard deviation of the measurement error is around 5.3 millimeters. This value was acquired under rather constrained circumstances and is based on rather short tanges, but still it gives an indication that my previous experiment with 5cm of noise is a bit unrealistic.
So I did the experiments again but now with 1cm Gaussian noise:
And here with 3cm of Gaussian noise
In my opinion WSM outperforms MbICP which in turn outperforms IDC, where the difference between WSM and the other two is more significant than the difference between MbICP and IDC. Of course, this is all highly subjective, soon I will follow up on all these results with a more fundamental analysis that compares the results against the available ground-truth.
Made a first step towards frontier extraction as described in Arnoud et al.'s 'Beyond Frontiers' paper. The FrontierLayer now keeps track of the 'region of interest' (in yellow) and the 'safe region' (in gray):
The current implementation is not be the most performant one and also it is not entirely correct, but that's an issue for later. The first step now is to extract the exterior of the 'safe' region, then subtract the walls and other obstacles and finally to compute the 'observation points'.

July 13, 2007

I figured out where I can make relevant changes to UsarSIM for my envisioned experiments:
Noise for the SICK and Hokuyo can be disabled in ~\USARBot\Classes\RangeSensor.uc (33), function GetRange().
Noise for the INS can be tuned or disabled in ~\USARBot\Classes\INSSensor.uc (183), Mean and Sigma variables in defaultproperties. The current implementation is reasonable as it uses Gaussian noise already (as opposed to the range scanner which uses uniform noise) and also the noise is applied to rotation and translation separately. Possible shortcomings are that the same noise model is applied to both rotation and translation and that it may be easier to apply the noise client-side so switching is easier.
The WSS cut-off can be set in ~\USARBotAPI\Classes\ComServer.uc (469), the eCutOff variable in defaultproperties.
Perfect Comm can be realized by setting this cutoff to a very high negative value (-10K), but it is cleaner to alter ~\USARBot\Classes\USARComServer.uc (124), function isReachable(), such that it always returns true.
Implemented Gaussian noise model for range scanner. Below the results that are obtained when the standard devision is set to 5cm. So, the 'true' value is perturbed with +/-5cm of Gaussian noise which makes for 10cm of nominal spread. The screencaps display the results with IDC, MbICP and WSM respectively:
These results are waaay different from those obtained yesterday without noise. Suddenly it's 'golden oldie' IDC that outperforms the other two and WSM dropped to last place. The stronger biased the scanmatcher the worse the performance so it seems. Perhaps 5cm of noise is a bit too much to be realistic, but the results are very interesting none-the-less!
Created a logfile in 'The Park'. The key difference with previous logfiles is that in this case the average scan is much sparser (many values at or beyond the max-range of the SICK LMS). So, the scan matchers will have fewer reference points for correlation and will need to determine the best match based on less information. When viewing the images below, keep in mind that the robot traversed a loop. I started in the lower-right corner, then zig-zagged through the park (the circles on the map mark the trees) and then returned at fast speed over the pavement that borders the park. The logfile comprises 800 scans that map an area of approximately 80 by 40 meters:
Apparently: less is more! In a way it makes sense, since there will be less distracting local optima. IDC is doing a fine job, some rotational error is introduced in the upper-left which causes the loop to 'overshoot' in the bootom-right. MbICP is doing really good, apart from some initial rotational offset it implicitly closes the loop almost perfectly. WSM is holding up quite okay too. The rotational error of approximately 30 degrees is introduced in several matches (perhaps only 1 or 2) at the upper-left corner. Other than that however, the map looks nicely matched, especially at the bottom things are razor-sharp.

July 12, 2007

Dogged persistence paid off, at last I got MbICP to work as it should. As it turns out there \was\ a bug in my code after all. Fixed it now, ManifoldSLAM + MbICP + INS:
What is interesting to note here is that MbICP seems to perform slightly worse than IDC (at least in terms of accuracy, did not compare performance measures yet),
Some more experimenting revealed that the previous result could be significantly improved by replacing the original convergence-check with the one I also use for IDC and WSM. MbICP used to consider itself converged as soon as 1 iteration yielded a new odometry estimate that was less than 0.1 mm or rad away from the previous estimate. This could lead too easily to situations where MbICP converges too fast (so actually does not converge) or to a local optimum. Now it requires at least 7 out the last 10 iterations to be below convergence thresholds, and also the threshold is now based on the root-mean-squared error between the correlated points:
So, now we can make an initial comparison between IDC, MbICP and WSM respectively. They now share the same point-correlation strategy, the same convergence check and also they were run from the same logfile with the same initial pose estimates from INS (click to enlarge):
This is getting very interesting! All of the scan-matchers yield maps of reasonable quality. WSM outperforms the other two on this particular logfile, and in my (subjective) opinion MbICP has a slightly better result than IDC. However, this logfile is a very 'clean' one, I am very curious to see how the results will compare when I start degrading the quality of the sensor readings by introducing more noise and/or sparseness.

July 10, 2007

Just before the RoboCup began Javier Minguez sent me a C++ version of his MbICP scanmatcher. Had a look at it today and immediately noticed one key difference with te Matlab implementation from a year ago: the point-correlation procedure is much more elaborate and full of thresholds and other biases that govern the decision when 2 points are to be considered as correlated.
Sent an email asking for clarification on what those thresholds mean. I get the feeling that part of the scan-matcher problem is being solved in the point-correlation stage already. This imposes a strong bias towards particular scenarios (e.g. indoors only) and also prevents a fair comparison with WSM and IDC. What I am thinking about now instead is to see if I can use just the metric from MbICP and fuse this into 'MbWSM' and 'MbIDC'.
Got a reply from Minguez already which confirms my beliefs about the C++ implementation of MbICP being strongly biased to a particular application. What I will do now is compare my VB implementation with the C++ implementation to make absolutely certain I did not introduce any bugs in the VB version. Then we will at least have a correct implementation in our framework. While doing that I will decide on the feasibility of 'MbWSM' and perhaps 'MbIDC'.

July 9, 2007 - Results

Yesterday our team had to pick up the final decisive battle. We had ended equal with SPQR on third place in the semi-finals, so another run was in order to decide who would become third.
We lost this battle. It's just too bad. We had a choice to make: freeze the code of yesterday or use a significantly improved version. We were very much aware what choice would have shown our wisdom. But we did not come there to be wise, we came to win! (Ignoring the fact that it is usually wisdom that leads to victory. ;-) ) Anyways, baldness it was, and we went with the improved version. Unfortunately it did not give us the anticipated benefit ...
So, we are 4th overall. Which I think is a great reward for our hard work. We have clearly demonstrated that we are a solid team that was a serious candidate to make it to stage. In some individual runs we have shown excellence in multi-robot exploration and mapping, and overall we have demonstrated to have a stable platform that delivers consistent and competitive results.
Now back to science. Will start documenting our achievements, and I have two papers to write. :-)

July 8, 2007 - Day 8: Battle for Third Place

We became third yesterday, but not convincingly. The difference with number 4 was only 2 points (132 for us over 130 for SQPR). Add to this that our run started too late (because of software problems) and SQPR delivered their map too late, and you know why the league organizers decided that we should do another run that will decide who is going to be third.
My focus is to get 'any level of autonomy beyond what we have now' working. Currently we have no autonomy, so this should be achievable. :-)
SVN Revision 674, under test (most probably stable): refactored CommActor <-> CommAgent relation so that CommAgent receives all relevant information about connectivity with other agents that it will want to forward to behavior control. So this revision does not add anything new, it is just a reorganization of affairs that paves the way for subsequent work on autonomy.
SVN Revision 675 to 679, buggy: while Tijn and me where on the phone, we committed several partial bug-fixes to aid communication.
SVN Revision 680, stable wrt 679: if 679 works, 680 will work too. Minor update that adds some debug prints.
SVN Revision 681, [update] buggy! Use 684 [/update]: major update to CommActor, CommAgent and several related classes. Each robot maintains a full connectivity graph and uses this to trigger a 'retreat' when a robot gets out of range of the operator. The retreat stops as soon as connectivity with the Operator is re-established.
SVN Revision 682 to 683, buggy: for communication purposes only.
SVN Revision 684, under test: fixed bug in revision 681. Broadcasted messages were delivered as many times as there are intermediaries forwarding them. This is okay and quite robust, but sometimes the older message arrives last which is of course not correct: the most recent message should never be 'overwritten'. Added this functionality to the CommActor.

July 7, 2007 - Day 7: Semi Finals

Our Team is showing good progress! From a 6th position after day 1, we climbed to 4th in the second run and managed to end 3rd in the last run of the prelims yesterday. So today we are still in the game, we are in the semis!
The spawn bug was due to using the GroundTruth as initial seed. This GroundTruth is of course only for debugging purposes and is disabled during competition runs.
SVN Revision 668: stable. Put a permanent fix in place for the bug where robots localize to (0,0), GroundTruth is ignored at all times now in release builds.
SVN Revision 669: stable. Disable anti-aliasing in buffered layer in order to preserve pure colors in our maps. By request of the jury, who want to auto-score our maps.
SVN Revision 670: under test. WARNING: NOT BACKWARDS COMPATIBLE! Implemented multi-hop messaging. So command relays and pose update notifications can now be sent through intermediaries.
SVN Revision 671: stable wrt 670. Tuned down manifoldimage resolution to 20 pixels/meter in attempt to improve rendering performance and enable apriori-files to be loaded during competition runs.

July 6, 2007 - Day 6: Indoor Scenario

Today we will be back indoors. Let's see if we can improve on our result of two days ago. It seems to be the same building, but I'm sure the creative people that build these maps will present us with some surprises as usual. :-)
We found out that yesterday's problems were mostly caused by a bug in the sync protocol. Most likely the effects of it were further devastating because of the different time settings on the used laptops (one was in GMT+1, the other in EST and the third was somewhere in between.... :-S).
Arnoud and Tijn had started fixing the bug already last night, this morning I was able to complete their fix
SVN Revision 656, stable yet slow: Arnoud's last commit that completes a partial fix after which at least the single-robot scenario seems to work flawless. For the multi-robot case there remains 1 bug. Then updates from Operator to robot will be sent back once (no more than that) until both correctly acknowledge the update as committed.
SVN Revisions 657 to 664: BUGGY, these are all to be ignored, either use 656 or update to 665.
SVN Revision 665, under test: revisions 657 to 665 document my progress as I fixed this bug for the multi-robot case. Initial tests indicate that the bug is fixed, more testing would be preferred.

July 5, 2007 - Day 5: Outdoor Scenario

Today we will face something like a parking lot after an earthquake ... Last year we had great trouble outdoors, since the range scaanner does not have as much reference data as it would like to. Hope Tijn manages to stay close to 'reference points' like cars, piles of rubble, buildings, etc.
Received a very clear 'bug' report from Tijn. Quickly discovered that this is not a bug, it's just a robot that got out of Comm-range. :-)
SVN Revision 641: augmented axis layer with x and y coordinates, very convenient
SVN Revision 642: Added thumbnail option to BufferedLayer in an attempt to improve rendering performance. This effects the FreeSpaceLayer (white), ClearedLayer (green) and ObservationsLayer (black dots). The quality of the visualization degrades noticeably, so when the map is saved on disk the thumbnail option will be ignored, so maps saved on disk will always be full-quality. Please note that creating the thumbnail is a trade-off: rendering speed should improve, but creating the thumb also costs CPU cycles. I'm not sure if and when the thumb is actually a benefit in CPU-terms, so I added a flag that enables to turn it off easily again.
SVN Revision 643: added real-time pose tracking to manifold view. It is no longer necessary to manually trigger a repaint of the view by panning it a bit or whatever would cause the view to invalidate. Also increased the size of the rendered patch-origins a bit, so that they are better visible.
SVN Revision 644: broken! Forgot one file
SVN Revision 645: buggy! [edit] Just discovered a bug with the FastFreeSpaceLayer, will be fixed in next revision.[/edit] Added FastFreeSpaceLayer which plots a single polygon instead of 181 scan beams.
SVN Revision 646: includes a bug fix for the FastFreeSpaceLayer, it now works nicely! Also added and tested speed-up and slow-down buttons for the AgentController. Noticed that SLAM \does\ keep up excellently if accuracy is concerned, but performance-wise the fast robots cause trouble (lag). I am considering to implement a simple filter that discards all laser scans that are retrieved while the odometry sensor tells that the agent did not move (or moved less than 2cm...).
SVN Revision 647: un tested! Modified ManifoldSLAM so that it will not match scans that are less than 2 centimeters or 2 degrees apart from each other according to INS or Odometry. Did a full run until the robot ran out of battery (little less than 20 mins), it seems to work nicely:

July 4, 2007 - Day 4: Indoor Scenario

UvA Rescue Team made it to the prelims! This means that we will at least have another 3 days of fun. Today we will face an indoors arena, so my SLAM is going to like it. Now let's see if we can get some robust Comm in place too, then we may be able to improve on yesterday's result.
Found a little bug with UsarSim not liking spaces in start-location and -rotation. Made some check in the AgentConfig so that these will trimmed if they occur again.
Found a major bug in WssConversation that caused the WssConversation to crash under certain circumstances. Fixed it.
Did lots of Comm testing all day. It all seems to work nicely. It is quite well doable now to operate 2 Pioneers from the Commander. Here I explored everything that is in range of the ComStation in 15 mins (Mapping-test arena):
Again Arnoud and Tijn were confronted with bugs I can not reproduce here. This is getting really frustrating! We decided to revert to the software that we used in the mobility test of day 1, that has been our most successful run until now.
Dick van Albada was so kind to bring pc-unreal over from the UvA. Set it up, had to upgrade UsarSim. I'm all set for some 'real' (or should I say unreal!) testing.
Fixed a bug with InsSensor/InsData that caused jumps in the Manifold to occur.
Uncovered another major bug, this one in SLAM. Below the map for 1st scenario that could have been, if it weren't for the bug ......

July 3, 2007 - Day 3: Mapping Test

Woke up early, received an email from Tijn about getting picture sharing to work. Will look into this after I checked SLAM on the Hokuyo + Talon.
Found and resolved a major bug in IcpScanMatcher. This improves SLAM with Hokuyo's quite a bit, but still quality of the map is way behind wrt those from the P2AT's with their SICKs. One cause is the limited range, but another major aspect is the offset of the Hokuyo wrt the Talon's chassis. Tried to make SLAM capable of dealing with laser range scanners that are not mounted at the chassis' center, but quickly found out that this requires a chain of changes that I won't manage in a couple of hours. So switched attention to other priorities first.
Apriori images contain 3 pieces of information, each encoded in a separate color channel. Red channel = mobility, green channel = victims and blue channel = Comm. This information is fused into one full-color RGB image, which made it rather hard to interpret (since there are 9 distinguishable colors, where each pixel mixes one of the 3 possible values for each of the 3 channels). So, I implemented a 'channel filter' which enables you to view a single channel at a time:
See also Aforge .Net Imaging library: http://code.google.com/p/aforge/
Started to work on behavior control. Want to implement something simple yet effective, the design for this is ready and implementation is halfway. Could not complete this since I got some very pressing bug report from Arnoud.
One hour before the run Arnoud contacted me that for some unclear reason the ManifoldView stays blank. There are no exceptions thrown, so we had no clue where to start digging for bugs. We went through all the obvious places and found some really weird things going on: the operator was updating the client's manifold ....?
Since the lastest version \does\ work for me, I can not reproduce the issue here. No matter what I tried, everything kept working just like it should. So we decided to have Arnoud do a clean SVN checkout, and with only several minutes to spare until Arnoud and Tijn had to start their run we got it to work. Pfew.......
Spent all night debugging Comm. Was at last able to reproduce and resolve several issues encountered by Tijn and Arnoud. Also discovered flaws in sync protocol, had to do a complete redesign which I got implemented early in the morning. Along the way i also got the path losses printed to the AgentController and made remote robots continuously send pose update messages.

July 2, 2007 - Day 2: Mobility Test

It took me the entire morning to get the apriori file handling right again.
The geotiff files provided are huge, rendering in Commander takes too long. I converted them to low-res thumbnails, which helps some, however rendering is still lagging.
Also the maps we deliver become huge due to the apriori files. This is because our map will at least cover the area indicated by the apriori file. Implemented a speedup for saving, but still .... perhaps it's best to NOT load apriori files in the Commander during competition runs.
Then shifted my attention back to WSS Comm. This it perhaps \the\ vital element that should be tested thoroughly for today's mobility challenge. No Comm => No deliverables => Failed challenge. Spent quite some time just running around some robots. No bugs found yet (!). Then spent some time on some of the more annoying things: it's hard to see where the agent currently is, and the Gui of lagging behind (not due to slow rendering, but due to the inherent delay in Comm.).
Remotely spawned agents now also communicate their current pose to the operator. This enables their rendering in the operator gui, very helpful! :-)
Tuned Comm so that the subsequent sync occurs after a second already. This provides more real-time feed-back to the operator. I do not dare to set this to zero (continuous sync) as I am not sure if this would cause the Conversation threads to consume all CPU resources.
Added min-range and max-range check to manifold rendering. Out-of-range values will no longer end in a black dot (= obstacle/wall).
Really COOL! Did a Gui crash-test, i.e.: spawned a robot, started Gui and then after 5 minutes I manually crashed the Gui and thus the Operator it hosts. What is really cool to see is that you can simply restart the Gui, respawn the Operator and after several seconds the Operator is updated by all the robots that are in range and everything returns to the state as it was just before the crash.
Also did the opposite test: crashed a remotely spawned agent. This scenario is handled equally gracefully. Basically: any robot may crash, as long as there is one robot that has a backup of the map all team members will be able to catch up after a respawn.
Laid out the basics for MotionControl and BehaviorControl. Got a really basic level of autonomy to work.

July 1, 2007 - Day 1: Setup day

Received emails from Tijn and Arnoud, they arrived in Atlanta and found access to internet somewhere. Also spoke to Arnoud over Skype, we divided the tasks currently at hand.
Last night Tijn fixed the bug in our victim reporting, it turns out that we were reporting all false positives too. Using Tijn's fix things look much better now:
Enhanced mapping delivery. The final map is now delivered in 3 parts: one 'map' file that is fully according the to the rules. All additional stuff has now moved to the 2 new overlays: one with the victim reports and one with the axes:
Also made the robot's trail gray instead of red.
Added min-range and max-range checking to ManifoldSLAM, surprisingly is has no positive effect on IDC. My earlier hypothesis that IDC suffers from distraction by out-of-range values thereby seems to be faulted. Somehow it seems to have a bias towards a slight rotational misalignment:
Implemented a 20% faster version of WSM

June 30, 2007

Relaying commands from operator to robots through WSS works.
Operator + Proxies model is fully implemented now and works: the Usar Commander spawns the ComStation and the robots are spawned remotely from UsarClients. Visualization of data received from the remotely spawned agents in the Commander and relaying commands from the Commander to the remote robots occurs through the Proxies that are hosted in the Commander.
Cleared area works. The ManifoldImage is extended with a new layer that paints the field of view of the VictSensor in solid green:
Another little victory, victim sensing and rendering works:
Next step is to make agents communicate victim observations ... working on that now
Partial victory: agents seem to communicate victims, but they turn up all over the map now. There could very well be a bug somewhere, but it doesn't seem to be an obvious one (since some observations DO end up on the right location in the operator's map).

June 29, 2007

Got Comm to work for the Manifold!
Agents now connect/disconnect/reconnect perfectly
They keep each other up-to-date on the latest changes to the Manifold. Using timestamps the agents keep track of who knows what so that they only send the recent updates to each other (as opposed to sending everything).
The sync-protocol implements some fail-safe checks so that parts that get lost during communication failures will be resent the next time.
To speed up the Comm all messages are compressed using Bzip2 compression, haven't measured the impact but it is significant.
Meanwhile, Tijn has been working on victim observations. I will make the robots share these tomorrow.
Other things that are to do: relaying drive commands through WSS, a cleared-area layer and victim-observations layer for the map, behavior control and motion control, ... two days to go, we'll see.

June 28, 2007

Spent most of the day at the ICIS event at TU Delft
Was quite useful though: we got a Talon configured with a Hokuyo laser scanner. ManifoldSLAM works with this differently configured sensor (270 degrees field of view) without a single glitch. The maps are worse than those of the P2AT because of the poor odometry of the Talon, but they still look pretty good.
The max-range issue is much more noticeable with the Hokuyo, this is because it only has a max-range of 4m (SICK LMS has 20m).
Also learned that even with the Talon some areas are unreachable (!). The only way to address those difficult mobility challenges seems to be by using the Talon's arm to actually 'lift' the robot over the obstacle.
Received an email from Minguez with C++ code, will look into this later.

June 27, 2007

Tijn came over to Gouda today
Discussed how to integrate our work into one coherent piece of code
Digged deeper into bug with disappearing victims, sent out a mail over the the mailinglist by the end of the afternoon
Got WSS to work such that every pair of agents will try to have an open connection whenever they are in each other's range
This connection gets lost when agents are too far away from each other, but is successfully restored when they get closer to each other some time later.
Also implemented a simple request-response messaging system using which I was able to make agents share parts of the manifold. At the moment this only gets triggered when a connection is (re-)established. Will extend this tomorrow such that agents keep updating each other and the operator.
I am thinking to add a timestamp to every patch. This will tell when exactly this patch was added to the manifold or last modified (e.g.: new victim observation). If robots also keep timestamps about when they last communicated, then it's rather easy to ensure they only send those patches to each other of which the other party was not informed yet.

June 26, 2007

Continued working on ProxyAgent
Found that the pathloss between 2 robots (or robot and comstation for that matter) suffers greatly from obstacles. Robots will need to share information with every other robot as much as possible to increase the chances that information will reach the ComStation.
Discovered a bug in the GETSS handling, sent it to the mailing list and several hours later it was fixed already (by Yasho), they are quick.
Done implementing GETSS handling. Each robot maintains a list of signal-strengths (to each other team member). This list is refreshed every 5 seconds.
Will meet up with Tijn tomottow, we'll try to integrate our work and get the robots to share victim information.

June 25, 2007

Made a design for a 'ProxyAgent'. During the competitions the Usar Commander is allowed to have access only to the information that comes in through the ComStation. So all other agents will have to be started externally, e.g. from the console. The ProxyAgent will not be a 'true' agent, just a proxy that monitors and controls the 'real' agent that is started externally.
This ProxyAgent should perform slam in an 'append-only' mode, i.e. the external agent performs the actual scan matching and slam so that the proxy only needs to append the patches as they come in through the WSS. In the opposite direction, the proxy should forward any commands from the operator to the real agent to have them executed remotely.
Before I could start implementing my design, numerous details had to be taken care of first. This is what I spent most of the day on. Tomorrow I will start implementing the ProxyAgent. First I want it to work for patches and relations, then for victim observations and images, and after that (and if time permits) I want to see if I can get the proxy to forward commands.

June 24, 2007

upgraded to newest usarsim release (3.13)
got WSS mostly done, agents can send text and binary messages (!), especially the latter is really convenient, since this enables the use of .Net's serialization methodology. Basically this means that any object that has been made 'serializable' (usually only requires the class-level <Serializable> flag) can be sent through WSS. The sender serializes the object to bytes and the receivers deserializes the byte array back into the full-blown object. So, the great convenience here is that robots can communicate objects, which alleviates us from having to write nasty string-interpretation scripts for any new message we want to support. All we need to do now is create a new object which is marked as serializable.
what remains is closing conversations, sending relevant messages and a redesign on several parts such that the Usar Commander can work with agents that are started remotely.
The aforementioned bug with message lengths does not seem to be a bug after all. The developer (Yasho Nevatia from Jacob's) explained that every message sent through WSS should end with a semi-colon.

June 23, 2007

Halfway done implementing WSS device in UvA Rescue framework
Multi-threaded design fully done, what remains are low-level message handling details
Successfully opened a connection between 2 robots
Successfully sent a message from one robot to another robot
There seems to be a bug in UsarSim with the messagelength. Perhaps this is fixed in the newest release of UsarSim, will check this out tomorrow.

June 22, 2007

Now fully understand how WSS is sopposed to work, know about all the possibilities and limitations. Digging into the inner-details of the Unreal Script files was of great value here.
In order to take full advantage of WSS (and we'll have to, even if we support everything possible communication will be rather limited) the WSS-related code will have to be a nicely designed multi-threaded device. The design is ready, implementation is in progress.
So, about those 'possibilities': a single agent can communicate to multiple team-members simultaneously. Even though this will have impact on the consumed band-width, it will still be of great value. Because then it will be quite easy to have all agents that are in range link up with each other and keep a open-line, perhaps only sending small pose-updates or messages to aid collaboration. These messages would only consume several bytes.
Came across something unexpected: it seems like a robot can query the signal strength between ANY pair of robots. Will test this soon, but it seems like a bug to me, not so realistic imo. Perhaps better assume that this 'feature' will not be present during the competition.
Update June 23: found in the usarsim mailing list that this is indeed no longer possible in current version of UsarSim.

June 21, 2007

Received an email from Minguez, he may supply me with an updated version of MbICP soon.
Received Luis' WSS code
Studied WSS and Luis' code, came up with an initial design for how to integrate Luis' efforts nicely into the UvA Rescue code.
Started implementing WSS, registering and listening works. Did not send/receive any many messages between robots yet.

June 20, 2007

Implemented MbICP. I'm getting the hang of converting Matlab to VB, only took me the morning (had to go to work in the afternoon).
Unfortunately, it performs terrible. Bug?
After work: nog bug, when I use the original Matlab implementation to process the same logfile as in VB the map is equally terrible.
At night: discovered that MbICP is extremely sensitive to outliers. This is due to the poor point-correlation procedure implemented in the Matlab code. However, also when using the much more elaborate point-correlation procedure that is already in VB the sensitivity/unstableness remains. MbICP will need an explicit step in which outliers are extracted. Question: how to determine which are outliers? Where is the balance between a dense scan with outliers and a sparse scan that is too sparse to match?
Sent an email to Minguez (first author of MbICP paper) to ask if he has any updated version of his scanmatcher. Unless I get an improved implementation I think I will discard MbICP.

June 19, 2007

Debugged IDC, implementation seems correct
Enabled resetting of Odometry and INS sensors, which means that each time SLAM localizes a robot, this pose estimate will be fed to the Odometry and INS sensors to take as the 'true' value on which to base subsequent sensor readings.
ManifoldSLAM + IDC + INS:
ManifoldSLAM + IDC + Odometry:
Observe that IDC performs better when it is seeded with initial pose estimates from the INS sensor. This is of course true for any ICP based scanmatcher as the chance for getting stuck in local minima lowers (assuming reasonable initial estimates), so also WSM would benefit from this.
One issue that is clearly visible in IDC + Odometry is with out-of-range values. During the point-correlation stage values that are out-of-range (i.e. less than 1cm or beyond the range sensor's max range) should be ignored. This is not implemented yet and clearly IDC suffers from this. Note that the map is fine (top and right side) until the first max-range values occur at the bottom. The funny thing though is that WSM apparently 'weighs' these long-range values away and hence does not suffer from this phenomenon. ;-)
The issue with out-of-range values does not occur when IDC is seeded with INS readings. This is because the INS bases its current values on the Ground-Truth + some noise. So even though IDC looses track, the INS allows IDC to correct itself as it will keep seeding IDC with values that are at most 'the amount of added noise' away from the ground-truth.

June 18, 2007

IDC works!
This well-known scanmatcher by Lu and Milios has been integrated into Usar Commander now
The map (ManifoldSLAM + IDC):
clearly does not perform as well as WSM, also: it's much slower

June 16, 2007

Usar Commander now comes with a super-fast map saving routine (takes several seconds only)
new SaveMapDialog to expose this functionality in the Gui
supports PNG, TIF, JPG, GIF and of course still GeoTIFF
produces TFW files to accompany non-tag-embedding image formats
Global Mapper supports TFW only in conjunction with (regular) TIF images
GeoTiffViewer supports TFW in conjunction with TIF or PNG
So these options (PNG and TIF) are turned on by default in the SaveMapDialog. JPG and GIF are still supported too, although they are probably not quite useful.
the extension 'TFW' derives from the first and last character of the image format it is referencing appended with the 'W' of Worldfile
- Hence: a worldfile for a TIF image = T+F+W = TFW
- Likewise: for a JPG image it would become JGW and for a GIF image GFW
So maybe the JPG and GIF are still useful, only then the TFW file should be renamed accordingly to make georeferencing tools accept it. Really low priority though, maybe when I \really\ have nothing else to do. ;-)

June 15, 2007

Not too much time today, many distractions
did fix the geo-referencing though (at last)
got a very insightful reply from Steve on how georeferencing works, apparently the convention is x-north/y-east. I never considered that y would be anything different from vertical (north-south), but yeah: that explains all my earlier confusion.
So, here goes: my map (ManifoldSLAM + WSM) overlaid with the ground truth
With the new insights I also finally understand how to interpret TFW files, I already found this description on Wikipedia quite some time ago (http://en.wikipedia.org/wiki/World_file):
- Line 1: A, pixel size in the x-direction in map units/pixel
- Line 2: D: rotation about y-axis
- Line 3: B: rotation about x-axis
- Line 4: E: pixel size in the y-direction in map units, almost always negative[3]
- Line 5: C: x-coordinate of the center of the upper left pixel
- Line 6: F: y-coordinate of the center of the upper left pixel
And now I can also get this to work as it should. Which is great news actually, since the GeoTIFF rendering using GDAL is terribly slow. I tested TFW files with TIF, GIF and JPG and it all works (both GeoTiffViewer and Global Mapper). So we can return to default Image saving using the .Net framework which gets the map on disk in a matter of seconds. Will fix this in our code this weekend.

June 13, 2007

Good progress today, got DeadReckoning to work. Basically this is the opposite of doing SLAM, as it means that the mapping software blindly trusts his sensor data as opposed to correcting the sensor measurements using scan-matching.
Using ManifoldSLAM + Weighted ScanMatcher:
When blindly trusting the Odometry sensor:
When blindly trusting the INS sensor: