Home
914 PC Bots Forum  


<< Start < Prev 1 2 3 4 5 Next > End >>
jamesbruton
Admin

Admin
Posts: 683
graph
Karma: 8  
Re:General Status??? - 2008/11/13 17:22 And I agree that having the same SW platform is crucial for any real progress, but that goes hand in hand with the HW also, having different HW that may or may not have the same capabilities can serve to de-focus any effort unless very well managed, and given this would be a community effort, then you cannot manage such a beast.

Partly true, but I guess a lot could be common if both robots appeared as a generic differential drive robot base in MRDS. Having looked at the Player/Stage stuff, you can use any supported robot, with any supported (laser) sensor, and then use the navigation/mapping/path planing algorithms that are provided to give the same functionality. If something similar to the Player/Stage suite were written under MRDS then it should work on the various supported hardware with only minor alterations.

My only point would be isnt this exactly what MSRS and player are there for?

Yep, agreed from my point of view anyway. I'm surprised there isn't a generic MRDS 'fan site' out there for many different robot owners to contribute code to.
  | | The administrator has disabled public write access.
croc999
User

Senior Boarder
Posts: 13
graphgraph
Karma: 0  
Re:General Status??? - 2008/11/13 23:58 Bit of a long winded post, hopefully it will address both of your posts......

To be perfectly honest I have not looked at MSRS much, I had started the python program long before MSRS started, I have had a few time lapses working on the python stuff so that is why it is only in its early stages. I'll take a look at it.

As far as player, this only runs on linux correct?, (at least the last time I checked), I'm not a big fan of linux, each time I have used it in the past I have spend more time getting drivers working and configured than working on the actual program, I know its gotten better, but I still have a bad taste in my mouth with linux, for better or worse there are more windows apps out there to draw from. I'm not a big fan of windows either btw.

As far as strabo, you don't need to supply a map, you could (and I have been tempted to try this) build a map on the fly based on sensor data, there are commands to place "tiles" on the strabo map so that you could build it based on the robots sensor data. But to be honest I don't see any benefit at this stage in robotics for a robot to build its own map, it is nothing more than a parlour trick, don't get me wrong its cool to watch, I have personally seen the vSlam app from Evolution run and its amazing how well it works, but when it fails the map gets screwed up really quick. As for the z axis, yea strabo doesn't do this, but I feel that dealing with this should not be on the table until the x,y navigation is as common and bullet proof as me being able to walk to the kitchen. I'm old fashioned that way , I think that before adding more features to something the base features should be solid.


Reason why I think itís a parlour trick. (not a viable business case)
1. for any commercial robot your not going to have the time to allow a robot to wander the facility so that it can build its map, plus there is no guarantee that the map will be complete, plus if a facility is anything like the ones that I have worked in there are always temporary things stacked in hallways that would distort the map. And you would have to have someone follow the robot around to make sure it
Didnít get stuck or lost during the mapping stage. And if it gets stuck/lost, the map building can go south really fast if the robot looses track of where it was, this causing you to start over. Its just too time consuming for this to be a viable business case.

2. for every robot you have you would have to go through the same process, could you guarantee that both maps would be the same?, very doubtful, so then with two different maps what do you do?, which one is more correct?, to determine this you would have to have someone compare them to the floor plan, again more time and money.

3. even after the map is complete you then have to verify that it does match the floor plan and then set up markers on the map that the robot can home in on to localize itself to make sure it does not wander off course and know what space is what. Think of it like this, when you join a new job, someone will show you around on your first day right, they will should you where everything is, so if we have to do this with humans why do we think you wouldnít have to do this with a robot. We don't typically tell people on their first day to "wander around and figure out where everything is".


Now all of this could be prevented by having a preloaded map that is loaded into each robot, then the robot could modify this temporarily to account for obstructions that are not permanent. And if there was a floor plan change (more cubes, walls, whatever) then you could push this map to each of the robots wirelessly on the fly. Now I cite business reasons, and I do this because once this is done for commercial use, then things trickle down to the consumer. For your own personal use sure let the robot wander and build a map, but from personal experience from vslam this take quite a long time and if the robot gets stuck it can then corrupt the map due to it thinking it is somewhere it isn't and things go south real quick. I have had to restart the map building several times and there we always some issue that popped up, so after several hours I still didnít have a good map ;-/
  | | The administrator has disabled public write access.
c6jones720
User

Platinum Boarder
Posts: 350
graphgraph
Karma: 3  
Re:General Status??? - 2008/11/14 03:43 You know what Im enjoying this! - I havent looked at my robot for ages but now Im starting to form new project ideas in my head.
Thanks guys this conversation has woken me up.

Now this whole thing about navigation and maps and viable business cases. SLAM if done properly is no parlour trick,
if you do it right it is a genuinely useful tool. Thing is its easier said than done. Like you said two runs are not going to
produce the same identical maps. They dont. If you run the program for long enough the robot ends up making a mess of the map anyway.

If the pictures upload, you can see a slam program I wrote for the 914 and how over a long period of time >20minutes the coordinates degraded.
What you should see though is that it did roughly trace out the shape of the room.

One procedure that you would probably be expected to use to improve matters is to use a Kalman filter. The Kalman filter makes use
of multiple sensory inputs and uses state space control theory to pull all the data together and make sense of it. This way we dont
just rely on say the infrareds, we could also take the odometry into account too alongside any other sensors that might be in there.
I havent used a kalman filter yet becuase I assumed it would be quite complex. I can see myself using one in the next year or so at work though.

Navigation is a big issue and theres no perfect way of doing it.

Ive tried using compasses - they drift and are always skewed by magnetic fields.
Ive tried GPS but it dosent really work indoors
Infrareds are okay but they tend to miss table/chair legs
File Attachment:
File name: 914_slam_images.zip
File size:47322 bytes
  | | The administrator has disabled public write access.
croc999
User

Senior Boarder
Posts: 13
graphgraph
Karma: 0  
Re:General Status??? - 2008/11/14 05:15 Glad to hear this thread has done something constructive

As you have noted, compass, IR's, GPS, etc all have their own issues, so they are not entirely reliable.
My approach for navigation and localization has been to have a fixed map that I created that I know is accurate, then on the map I have placed a few (need to add more) image markers that my robot has been trained to recognize, sort of like visual waypoints, that will allow it to find where it is located and then when travelling to a destination it can then check its progress along the way to make sure it is heading in the right direction. So by doing this if it "sees" and object that it knows, it can get a rough estimate of its location in relation to the object, this combined with compass, sonar and IR data can then be refined to be pretty close to its real world position. Based on the testing I have done, this works out pretty well, but this is still a work in progress.

Other things that can be done for compass/odmetery drift that I have planned to add is using the existing walls in a home, for example if your in a hallway, use the walls on each side, or even a single wall, if the robot maintains its relative distance from the wall then you can be pretty assured that you are travelling in a straight line regardless of the compass reading, since most hallways are straight.
Or if in a hallway (most hallways are a known fixed distance wide so a few sensor readings and the robot can guess reasonably well that it is in a hallway) the robot can correct its position by centering itself within the hallway, this will minimize avoidance issues when passing through doorways.


The issue that I have with self mapping is that once the map is created a human then needs to interact with it to set up some sort of marker or clean it up etc, so my point is that if you have to do this anyway why not just give it an accurate map to start with. Would I like to see a robot create a map and then have it be able to completely and accurately use this without human intervention sure, but that is quite a ways off, so I would prefer to tackle getting the navigation/localization side down to where it is so common place that its not even considered cool (the way we take windows for granted, remember the apple II ascii interface ), then tackle the next progressive step, but we can agree to disagree on this. Nice pics by the way, I'm not apposed to vslam, I just think we are too early in the curve for it to be useful, there are bigger fish to fry, IMO

IR sensors as you note are good but not great, same goes for sonar, what I have done is mounted them both as a pair for the front and side facing sections of my robot, so between the two sensors I should be able to leverage both of their strengths to get better data than from just single sensor, again this is still in progress, I have the IR function completed and tested but have not had time to combine the data from both as yet.
  | | The administrator has disabled public write access.
GRUNT
User

Platinum Boarder
Posts: 86
graphgraph
Karma: 5  
Re:General Status??? - 2008/12/01 07:17 Great input Croc999 and C6jones. I can't believe I've missed your dialogue up until now.

I think once we get a charging station for the PC-BOT all sorts of applications will immerge.
  | | The administrator has disabled public write access.
c6jones720
User

Platinum Boarder
Posts: 350
graphgraph
Karma: 3  
Re:General Status??? - 2008/12/02 22:21 Yeah I am surprised nobody has done anything about charging the robot, it strikes me as an obvious starting point.
  | | The administrator has disabled public write access.
<< Start < Prev 1 2 3 4 5 Next > End >>