Changing Directions April 19, 2010
Posted by chenfriedman in PhD Thoughts, Project Related Posts.Tags: MAV, Obstacle Avoidance, SLAM
add a comment
This post was written in about an hour so it’s mostly me blowing up here.
After many tedious discussions with a person to whom I hold the deepest respect, and with my advisor, I was finally able to explain the real and only part of SLAM in our project. I now understand that having a robot (ground or aerial) do SLAM looks a bit magical since it is usually accompanied by the robot performing other tasks such as path planning, carrying out a search mission, or avoiding obstacles. Therefore I was not surprised that it was “clear” to some people including the above mentioned and many of the colleagues in my research group that SLAM is also responsible for some or all of the above features. Let me set the record straight: SLAM is nothing more than Simultaneous Localization And Mapping. Taking this as literally as possible means that given some sensors as inputs, the SLAM algorithm can produce a map of the environment as it discovers it (within it’s viewing range) while maintaining the robot’s pose within that environment. That is it. SLAM is not responsible for planning path (what’s the path from A to B), decision making (should I choose one path over another), or obstacle avoidance (avoiding collision with stationary or moving objects). There is no better way of saying this than the following: SLAM takes sensory inputs and outputs map and pose only. regardless of the details of how you output a map, a robot performing the task defined as “from A to B” needs to have the following:
- SLAM
- Path planning (or motion planning)
- Obstacle avoidance (static at the very minimum and hopefully dynamic as well)
- Decision making process (If there is more than one path – which should I choose)
After an extensive literature research that spanned the past 6 months, I would like to verify the following with my readers:
- For helicopter UAVs there are only two or three Universities in the world that have implemented SLAM on a helicopter MAV (MIT, University of Pennsylvania and I believe Stanford)
- There is no way/method/procedure to perform SLAM without estimation theory while at the same time have a fixed upper bound on the error in pose or map (I know of the work by Olivier Garcia, but the error that I’ve see in his work is about 1% hence it is unbounded)
- Every SLAM procedure requires a model of the vehicle and to the best of my knowledge all helicopter vehicle models are linear (i.e. x_dot=Ax+Bu)
If anyone else knows otherwise about any one of the above mentioned conclusions – please inform me via email or a comment (I most appreciate your help on this issue).
As a result of this understanding and due to the fact that nor I, nor does my advisor or his group have sufficient knowledge in estimation theory, I decided on a change in direction for my thesis. Not to worry, this blog’s name would still remain “From A to B” but instead of getting from start to goal, I would start off with a given coarse, starting at point ‘A’, and I will perform dynamic obstacle avoidance that would eventually try to reacquire the original coarse at a certain point ‘B’.
How does that solve my problems? well, I can assume that I get (x,y) position from the “guys who’re doing SLAM”, in the mean time I can get away with replacing that information with pose input from systems such as Vicon or even for starters – simple odometry (although noisy and drift-prone).
I guess that’s it for now, it’s a lot to assimilate, even for me, but I do believe with all my heart that taking this direction change would bring me to my personal ‘B’ point much faster and with greater contribution that is far more related to helicopters. I believe that at some point you have to maintain a reasonable part of your thesis in the area of your expertise, and mine is not estimation theory.
I have a lot more to tell you about the new exciting project, but I’ll leave it to another post. Thanks for reading this and I’ll most appreciate even the most random links that might help. Questions are, as always, mostly encouraged.
C
Global Coordinates Video March 31, 2010
Posted by chenfriedman in Progress Reports, Project Related Posts.Tags: drift, global coordinates, laser scanner, Scan Matching, SLAM
add a comment
After computing the motions between one laser scan and another, you can project all the scans to the initial global coordinate system and compute the relative robot pose in reference to that coordinate system, to get the bird’s eye view of your robot motion and the incremental map that is being produced. Of course not all motion estimates are absolutely accurate hence the path and the evolving map have significant amount of noise that can only be minimized but not avoided altogether.
Please view the following video (also on youtube):
In this particular example (one of many to come) the vehicle was constrained to move in a straight line by a track that I built. Track length is about 7 meters and some boxes were used as obstacles for the vehicle to map. At the end of the track I placed a “final wall” where the vehicle stops.
What you see is the vehicle motion estimate and the map generated by the algorithm. Explanation: red dot – vehicle, red arrow – shows vehicle direction, blue dots – laser measurements that participated in the scan matching and were recorded as part of the global map.
The bad news: as expected due to previous work review, the estimated path and the corresponding map that was generated are far from being consistent with the true path and map. In this particular video – the vehicle pose estimate drift to the left and the resulting map curves in the same pattern. It was not the case with all the experiments but the severity of the drift (more than one meter over only 7 meters coarse length) is such that requires major corrections.
Stay tuned for future results…
First Scan Matching results March 2, 2010
Posted by chenfriedman in Progress Reports, Project Related Posts.Tags: Scan Matching
1 comment so far
I was able to construct a program in Matlab that implements a basic scan matching algorithm. Basically you have two subsequent laser scans (each is a bunch of laser range measurements at specific angles) and you try to infer your vehicle’s motions from the first scan to the next. The figure shows the incremental x, y motions and the lower figure show incremental rotations (marked with psi). The algorithm is fairly simple and I’ll try to improve it during the next week. Also it runs pretty slow so it cannot be done on the fly as laser scans are being generated by the scanner (typically at 10Hz).
Is it that complicated? February 26, 2010
Posted by chenfriedman in Project Related Posts.add a comment
It is sometimes hard to come up with a good concise description to the physical/mechanical/computational problem you’re dealing with, whether you explain it to laymen or to experienced people (with all sorts of academic degrees). The difficulties are that laymen don’t have the background and you cannot use terms that are trivial for you and are part of the language you use in your everyday life, and the professionals – well, they usually have a fixed state of mind as to how they understand things should look like or in what way would you pursue a certain research. Often professionals would also have attitude which could possibly cloud their judgement as to your research.
Even yours truly have failed to understand the research process of person X a few times in the past just because he thought that he would do it differently and failed to see the goal through the other person’s eyes (the problem is being treated). So in fact, sometimes it’s easier to explain to the laymen… At least they end the conversation saying things like “well it sounds like rocket science to me so you’re probably very smart”…
So I’ll give it a shot.
Think about this: You wake up in an indoor space and you know that the exit is 20 meters to the North but now you need to get there. The way to do it is to generate a map of your immediate area while keeping yourself localized within that map (A.K.A. SLAM in the robotics community, which stands for Simultaneous Localization And Mapping). If you’re interested in the comparison between a human and a machine for this particular problem – visit the page named “Who’s Better?” on this blog.
Using the same example from one of my pages, it might remind you of the movie “Cube” (1997) except that the people that woke up inside the cube did not even know where the exit is, in which cased you have to keep mapping every place you visit until you find what you’re looking for (I’m not gonna put a spoiler so you’ll have to watch to see if they made it out or not).
Occasionally you hear people say “how come we don’t already have humanoid robots doing exactly what humans can do (and being better at it)? Well, if you ask a robotics expert, it is likely that his answer would start with “Oh it’s very complicated, you see….”. Not that helpful is it? I will not attempt to explain or list the many issues with humanoid robots, as it is unrelated to my project, but I would like to give you a glimpse into the main issues in my project just to get you thinking about the problem.
To explain the major difficulties of my project, you have to see things through the eyes of a machine, while considering only the capabilities that you place on your platform. I know, it’s hard, since we’re humans and some tasks look so trivial to us but when you try to break it down to machine elements (computer, memory, software, algorithms, sensors etc.) it turns out that suddenly – you don’t know how to spell it out to the machine. Sentences such as “can’t you SEE it’s a window??” or “Why didn’t you go THAT way can’t you tell it’s so much shorter?” can be pretty common when humans interact with robots (GPS telling you to go through some weird route, rings a bell?).
It is obvious that your aerial vehicle has to do the following tasks simultaneously and on the fly (while in motion):
1. Create and store a map of it’s surroundings
2. Tell it’s position within the boundaries of the generated map
3. Avoid collision with obstacles
4. Plan a path going from where you are to where you want to be (in other words – from A to B)
As many have said before me – it’s easy to do either task by itself but combine all of them to a unified single capability is an altogether different problem to consider.
If only we could teach machines to “see” like humans, be able to infer distance with reasonable accuracy, have three dimensional vision capability, have a brain that can combine information from all available sensors (vision, sound, motion, touch), and come up with a highly probable conclusion within as little as half a second – then we’re guaranteed success in this project. But then again, it’s THAT complicated!
