Hi All,
After a long year we have reached the end of our Engineering Project. It was a lot of work, and sometimes a lot of frustration but in the end it was also fun and rewarding.
All our work is detailed in the Project Book.
The Project Presentation Day event in which we have won the "Best Project" prize (see the previous post for more detail) was reported in the main page of the School of Engineering and Computer Science. If you are interested, here is the link.
So that's it, we are done :)
Yair
Friday, September 26, 2008
Thursday, September 4, 2008
Winning :)
About a month ago, on the 30th of July the School of Engineering and Computer Science of the Hebrew University held its annual Project Presentation Day, in which all the final year's engineering projects are presented, and a few winners are declared. We were happy to find out that our HANS project has been selected (together with two more projects) as the best project of the year :)
Below are some photos from the event
Below are some photos from the event
Monday, June 16, 2008
Robot ghost from the past, and an Obstacle avoidance algorithm
As some of you might know, the engineering labs in Ross building were closed in order to
dedicate them for other uses. In return we got 2 spanking new labs in the Levi building.
The first time we used our new labs, everything was still unorganized and stored in cardboard
boxes. I started snooping around, digging into boxes to see if I could find some dry erase markers
for our white board. In one of those boxes, under a pile of cables and two big books about circuit design I had a glimpse of some red casing and one black wheel. After removing those obstacles I found myself staring at a Pioneer 2DX robot - A bit old I have to admit, but still one of the most popular platforms for robotic research around. Apparently (so we were told afterwards) it was originally bought for a course that took place in 2001, and after that remained out of sight (and out of mind) for 7 years, locked in a closet.
We immediately went to work trying to get it to show some signs of life, and after two charging sessions of about 12h each its batteries became fully operational again.
Our development platform (Player/stage) is especially suited for working with this type of robot so we quickly got it to communicate with the Pioneer and realized that, considering its old age and storing conditions, it is in pretty good shape - 7 out of its 8 sonar sensors are working (only the front one is bad), and so are the wheel encoders. I don't have to tell you that obstacle avoidance becomes much more robust when commanding 7 sonar range finders that when only working with 1, so we combined the information from these sensors into a much nicer obstacle avoidance algorithm. :)
I'm posting some pictures of the new robotic base, and two videos of obstacle avoidance in action. As before, one shows HANS making a complete mess of things, and the other shows the algorithm after more debugging successfully traversing the little obstacle course.
Here is the new (old) base, isn't he a looker?
Trying, but failing.....
This time, a much better performance
dedicate them for other uses. In return we got 2 spanking new labs in the Levi building.
The first time we used our new labs, everything was still unorganized and stored in cardboard
boxes. I started snooping around, digging into boxes to see if I could find some dry erase markers
for our white board. In one of those boxes, under a pile of cables and two big books about circuit design I had a glimpse of some red casing and one black wheel. After removing those obstacles I found myself staring at a Pioneer 2DX robot - A bit old I have to admit, but still one of the most popular platforms for robotic research around. Apparently (so we were told afterwards) it was originally bought for a course that took place in 2001, and after that remained out of sight (and out of mind) for 7 years, locked in a closet.
We immediately went to work trying to get it to show some signs of life, and after two charging sessions of about 12h each its batteries became fully operational again.
Our development platform (Player/stage) is especially suited for working with this type of robot so we quickly got it to communicate with the Pioneer and realized that, considering its old age and storing conditions, it is in pretty good shape - 7 out of its 8 sonar sensors are working (only the front one is bad), and so are the wheel encoders. I don't have to tell you that obstacle avoidance becomes much more robust when commanding 7 sonar range finders that when only working with 1, so we combined the information from these sensors into a much nicer obstacle avoidance algorithm. :)
I'm posting some pictures of the new robotic base, and two videos of obstacle avoidance in action. As before, one shows HANS making a complete mess of things, and the other shows the algorithm after more debugging successfully traversing the little obstacle course.
Here is the new (old) base, isn't he a looker?
Trying, but failing.....
This time, a much better performance
Monday, June 9, 2008
Obstacle awareness and HANS in its complete form
We have been working (amongst other things) on HANS' obstacle avoidance system. Planning a path around obstacles and continuing on the desired path is not a very simple task, but in the mean time we got HANS to at least be aware of its surroundings and refuse to collide into objects. This is done using the sonar range finder mounted at the front. The sensor is very unreliable and so we need to take into account the last N readings in order to make intelligent decisions. This can potentially cause slowness of reaction, that is realizing an obstacle is on the way a bit to late to actually stop in time to avoid collision. We had to fine tune the parameters of the algorithm (The number of readings to use, the threshold distance to signal an obstacle etc') in order to get good results. I'm attaching two videos that show, first, a failed attempt and then a successful one.
1) Almost made it :)
2) Here we go ...
I also noticed that we haven't uploaded a picture of HANS in its final form, with laptop, sonar, camera and all . So I am placing a couple of those here now, and I also changed HANS' profile picture at the top of the blog.
1) Almost made it :)
2) Here we go ...
I also noticed that we haven't uploaded a picture of HANS in its final form, with laptop, sonar, camera and all . So I am placing a couple of those here now, and I also changed HANS' profile picture at the top of the blog.
Thursday, May 29, 2008
More path detection updates & videos
Following a suggestion by Nir I changed the algorithm to work using offline sampling for the creation of the road and non-road models, I built a small application that allows a user to highlight areas that should be included in the road/non-road model and used it to train the GMM on some path images I've taken (the rest of the algorithm is the same, read the previous post for details).
This has improved the performance of the algorithm and helped reduce running time a little bit, but the algorithm still has difficulties with some scenes, mainly when shadows are involved.
I'm posting 2 nice videos that show the algorithm's abilities :)
1) Detecting an obstacle
2) Moving between two types of paths
This has improved the performance of the algorithm and helped reduce running time a little bit, but the algorithm still has difficulties with some scenes, mainly when shadows are involved.
I'm posting 2 nice videos that show the algorithm's abilities :)
1) Detecting an obstacle
2) Moving between two types of paths
Wednesday, May 7, 2008
Path Detection algorithm - Now we are getting somewhere :)
hi All,
The exam season was appon us and along with the passover holiday caused the project to slumber a little bit. When it was over we got back into full development mode.
While Keren & Dror started working on local map building and path planning I returned to working on the path detection algorithm. After spending a lot of time on the localization module, tweaking noise parameters and believe functions, it felt good to switch to a completely different type of work.
Here is a short description of the algorithm as it is now:
I start by sampling 2 small rectangles in the picture - one at the bottom is used as an example of road pixels and the other (sampled from the top of the image) is used as non-road pixels.
From each rectangle I build a data set and train a mixture of Gaussians over the RGB space, which provides a model for road (or non-road) pixel distribution. Then I calculate the probability for each pixel in the image to belong to either one of the models and classify it according to Maximum Likelihood.
This provides a pretty good first guess as to which part of the image is the road, but it still lacks the accuracy needed for HANS to reliably drive on the path.
I decided to try and use a technique used sometimes in image segmentation - applying the known min-cut algorithm.
It basically works by building a graph where nodes are image pixels and edges are connections between pixels. The Source and Sink nodes are the labels (in our case Road and Non-Road) The cost to cut a node from the source/sink is the probability it belongs to the appropriate Gaussian Mixture. The cost to break an edge between to pixel-nodes is based in pixel color similarity. The min-cut algorithm is then used to find the cut with the smallest cost.
This produced much better results! The video included with this post shows 4 stages in the detection process:
1) the original frame is captured.
2) The GMM are trained and used to classify the pixels.
3) Min-cut is used to create a better segmentation between road and non-road parts.
4) the drivable area is marked ontop of the original frame (in red).
As can be seen in the video the results for most frames are excellent, but some frames still have a bit of trouble, this is common in the group of videos I tried it on. In addition, while most of the steps in this algorithm (GMM building and ML classification) are very fast, using the min-cut approach is very costly in terms of running time. As a consequence the algorithm works at a speed of approx. 1.5 fps.
So my upcoming work on this module will focus on these directions:
a) Gather more test data and see how robustly the module handles them.
b) Fine tune the parameters of the algorithm to try and overcome the difficult frames.
c) Improve the total speed of the algorithm. To do this I might need to find a different approach than min-cut. One idea is to use only Gaussian mixtures but have them adapt to changes over time (as was done by Thrun et al., Stanley: The robot that won the Darpa grand challenge)
That's it for now, I will post more news as the occur.
Happy Independence day :)
The exam season was appon us and along with the passover holiday caused the project to slumber a little bit. When it was over we got back into full development mode.
While Keren & Dror started working on local map building and path planning I returned to working on the path detection algorithm. After spending a lot of time on the localization module, tweaking noise parameters and believe functions, it felt good to switch to a completely different type of work.
Here is a short description of the algorithm as it is now:
I start by sampling 2 small rectangles in the picture - one at the bottom is used as an example of road pixels and the other (sampled from the top of the image) is used as non-road pixels.
From each rectangle I build a data set and train a mixture of Gaussians over the RGB space, which provides a model for road (or non-road) pixel distribution. Then I calculate the probability for each pixel in the image to belong to either one of the models and classify it according to Maximum Likelihood.
This provides a pretty good first guess as to which part of the image is the road, but it still lacks the accuracy needed for HANS to reliably drive on the path.
I decided to try and use a technique used sometimes in image segmentation - applying the known min-cut algorithm.
It basically works by building a graph where nodes are image pixels and edges are connections between pixels. The Source and Sink nodes are the labels (in our case Road and Non-Road) The cost to cut a node from the source/sink is the probability it belongs to the appropriate Gaussian Mixture. The cost to break an edge between to pixel-nodes is based in pixel color similarity. The min-cut algorithm is then used to find the cut with the smallest cost.
This produced much better results! The video included with this post shows 4 stages in the detection process:
1) the original frame is captured.
2) The GMM are trained and used to classify the pixels.
3) Min-cut is used to create a better segmentation between road and non-road parts.
4) the drivable area is marked ontop of the original frame (in red).
As can be seen in the video the results for most frames are excellent, but some frames still have a bit of trouble, this is common in the group of videos I tried it on. In addition, while most of the steps in this algorithm (GMM building and ML classification) are very fast, using the min-cut approach is very costly in terms of running time. As a consequence the algorithm works at a speed of approx. 1.5 fps.
So my upcoming work on this module will focus on these directions:
a) Gather more test data and see how robustly the module handles them.
b) Fine tune the parameters of the algorithm to try and overcome the difficult frames.
c) Improve the total speed of the algorithm. To do this I might need to find a different approach than min-cut. One idea is to use only Gaussian mixtures but have them adapt to changes over time (as was done by Thrun et al., Stanley: The robot that won the Darpa grand challenge)
That's it for now, I will post more news as the occur.
Happy Independence day :)
Thursday, March 27, 2008
Localization results
Here are results of our localization algorithm.
We start by showing simulated results to see why using only the GPS or the wheel encoders is not enough
Now lets see how the particle filter algorithm can help
and, just for those of you with less then 20/20 vision lets see some comparison graphs
finally we show a little video of the results of a real localization run
We start by showing simulated results to see why using only the GPS or the wheel encoders is not enough
Now lets see how the particle filter algorithm can help
and, just for those of you with less then 20/20 vision lets see some comparison graphs
finally we show a little video of the results of a real localization run
Subscribe to:
Posts (Atom)
