If you want to spend some time wondering:
"will it close the loop, will it close the loop .... "
Download the appliction...
Diversity Grid Slam Explorer Beta - release notes
enjoy!
Wednesday, 2 May 2007
c# Grid SLAM explorer
This c# application was made as a test ground for a grid slam algorythm that I'm preparing for a Microsoft Robotics Studio service. It allows you to tweak most of the parameters of grid slam including motion errors, the number of sensors, their placement, beam models and cone models for each sensor. It was designed for sonars but includes presets for infrared and laser.
If you want to spend some time wondering:
"will it close the loop, will it close the loop .... "
Download the appliction...
Diversity Grid Slam Explorer Beta - release notes
enjoy!
If you want to spend some time wondering:
"will it close the loop, will it close the loop .... "
Download the appliction...
Diversity Grid Slam Explorer Beta - release notes
enjoy!
Subscribe to:
Post Comments (Atom)
19 comments:
Thank you, trying it out.
Did you receive my mail?
Hi, again.
After a quick look at it:
- The robot seems not to be able to rotate/turn. Obstacle aviodance always shows "no save path found".
Same thing while mapping. Always moves straight into the walls.
- When loading a logfile (eg loop5) the following exception occurs:
************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Just as a short feedback.
Nice work.
Yep, the log file support isn't complete yet. It isn't finding the file. If you try copying loop5 up a directory it might work.
I dont' have a robot that makes that kind of file, so I haven't concentrated on that side of things yet ... sorry. I probably should have cut that feature out, as everyone's logfile will need meta parameters to explain them and 180 lasers making points doesn't suit the algorythm too well.
Here's an image of the obstacle avoidance prob.
robot moves through walls:
http://img130.imageshack.us/img130/148/imagejn5.gif
I can't reproduce that with default settings.
It is very easy to do though. If you increase the valley threashold of VFH to 0.6 you are effectively saying that walls aren't walls, and the robot is happy to oblige.
Going to test further.
I'll let you know.
By decreasing the valley threshold (it was already smaller than 0.6 yesterday, I had left the standard settings in this section), maps get slightly more promising.
But the core problem with the "noclipping cheat" persists.
http://img176.imageshack.us/img176/1842/settingsvy5.gif
http://img176.imageshack.us/img176/4529/mappingqp8.gif
I can repeat that kind of map by making the robot move fast and giving it tons of motion noise. Again this is to be expected. If all the model parameters are not within a certain range, then it can fail easily - this is part of what I hope the app shows: That Grid SLAM (as implemented here at least) is somewhat fragile and only works when the right balance is achieved between motion noise, sensor overlap and interpretation confidence.
If you say that you get this result off the default settings just after launching, I can only guess that something in the app doesn't like Vista. Others seem to have no problems.
It's XP.
Which .NET Framework are you working with?
Hi Jason,
It is made with .net2, so should work or not at all. Can you confirm that after launching you get weirdness before messing with parameters?
yes.
Launch."DoSLAM". No parameters adjusted. The result is shown on the picture(s) above.
Maybe this could be a hint:
When I'm in the dialogue for the motion model (and leave settings untouched) and hit "step" several times, the red dots indicating the robots real position move as expected - but all the particles stay around the origin and seem not to be updated with the odometry each step.
So maybe there's a bug in updating in the particle filter?
http://img337.imageshack.us/img337/4917/pfml6.gif
Robot (settings untouched) moves some steps forward, then turns for one step and moves forward again. The particles just get more and more noise but the actual move seems not to be taken into consideration.
Picture didn't work. Here's a working link:
http://img412.imageshack.us/img412/6672/pfmj3.gif
The problem looks very numerical - huge random noise. My guess is that you are in a locale which uses ',' as the decimal separator instead of '.'.
You might be able to temporarily change your local, or change all the dots to commas while I work on a fix, if it turns out that that is the problem.
You should be seeing something like the Motion Error Art post.
That was it!
Thank you very much for illumination :)
This looks like a good start. To improve the performance you need a learning algorithm to automatically optimise the various parameters such as the beam model.
Hi Bob,
Actually I have one of those tucked away. I snipped the button off the interface because it didn't make much sense to learn how random the system's random number generator was. The trouble with EM algorythms is that you need the truth baseline which in most texts I've seen effectively comes from someone noting time and position from gridlines on the floor. I suppose after a while of mapping, if a consistent map was produced and if the location certainty remained high, then it could tune its models to represent the truth.
Otherwise I was going to make some automated routine where it faces a big wall and moves back a bit, back a bit more while gathering data. This would give a broad picture but wouldn't adjust for cone width, clutter and unexpected cats etc.
Hi there, nice SLAM.
Can I download the app, decompile it to source code, change it and use it on my project? It is not commercial project.
Thanks for reply.
Hi!
i want to this project source code.
but download link is dead..
please.. send me e-mail (ksydiary1@gmail.com)
Post a Comment