Hi all, I hope you enjoyed reading my posts for my accomplishments this summer.
I would like to take this time to say a couple of my last thoughts about EURECA.
So, I have been involved in the Pharos robotics team this summer to develop a couple of tasks for our new Proteus platform.
Like I explained in the last post, most of the milestones came together in the last few weeks of the summer when we were able to work with more robots instead of simulation.
I wish, however, that I had a stronger background in the underlying theory so that our algorithm is fortified with the backbones of concrete theory.
Most of the algorithm that we developed this summer was tweaked in order to best fit the goals of Proteus.
It was an ineffably amazing experience though, when the robots started following the lines and avoiding cardboard walls we made!
Participating in hands-on research programs like EURECA is a definite refreshment from the theoretical world that we all enjoy (!?) in school.
Overall, I felt like I opened my vision towards engineering; for those of you that are more stimulated by the hands-on experience, this is a great program for you!
The amount of community in the group was also fantastic, and was exciting to attend the numerous social events that were set up this summer.
Alright, that might explain most of my thoughts. Thanks for reading!
-- Arthur
Saturday, August 7, 2010
Thursday, August 5, 2010
EURECA research summary
I've experienced a full 9 weeks of the exposure to great experience with the Pharos lab group.
Let me summarize the accomplishments that were made this summer by our team.
If you remember my second post, our goal was to develop new tasks to the new Proteus platform.
In my previous post, I clarified that those two tasks were line following and obstacle avoidance.
Although coming up with different algorithms and ideas for actually writing the codes for the tasks were not difficult, testing them on both simulation and physical robots became a challenge for our software guys (where I mainly lived in this summer).
Simulation:
There were various simulation driver settings and environments that weren't entirely reliable in the goals that we wanted to achieve.
For example, there was a camera driver called blobfinder in the player library, along with a driver called ptz (pan tilt and zoom) for control features for the camera.
However, the ptz driver was not available for the current version of Stage simulation, so the robots within the simulation environment could only look straight forward.
Physical robots:
For a substantial portion of the summer, the hardware parts for the sensor plane were not available.
This caused a delay in the number of robots that we were able to test with, and that became a huge problem for things like obstacle avoidance, which we wanted to run on multiple robots.
However, most of the hardware sources became ready recently and we now have had three robots to test with!
Getting back to the updates on development of those two tasks:
Line following:
Since about two weeks ago, we started to test our algorithm using thin black tapes.
We drew arbitrary paths and turns in order to see the strengths and weaknesses of our code.
For slow speeds (up to about 0.4 m/s), our implementation works fantastic!
We did have a problem with sharp turns, where our robots were not able to track the lines fast enough and would lose the lines.
Replacing the thin tapes with thicker tapes may have helped, but this may be the fact that turns are no longer as abrupt as they were when the tape was thin.
There is definitely more room for this task to grow and to improve, such as making use of the ptz driver in the future.
Obstacle avoidance:
You might remember that I talked about an already developed algorithm called VFH.
VFH was embedded as a player driver, but it expected a solid destination point, which our subsumption system does not support (only collects instantaneous velocity and turn angle).
The VFH driver was also difficult to turn on and off within our code, which lost our desired modularity for using tasks only of high priorities.
The software guys and I eventually decided that we should borrow the ideas of VFH and to write a mimic algorithm within our code, so it can be easily fit into subsumption.
Our current code works pretty well, but more tests can be done in our next stage in order to fortify the effectiveness of our code for multiple robots.
Plotting efficiency of my research v. time:
Let me summarize the accomplishments that were made this summer by our team.
If you remember my second post, our goal was to develop new tasks to the new Proteus platform.
In my previous post, I clarified that those two tasks were line following and obstacle avoidance.
Although coming up with different algorithms and ideas for actually writing the codes for the tasks were not difficult, testing them on both simulation and physical robots became a challenge for our software guys (where I mainly lived in this summer).
Simulation:
There were various simulation driver settings and environments that weren't entirely reliable in the goals that we wanted to achieve.
For example, there was a camera driver called blobfinder in the player library, along with a driver called ptz (pan tilt and zoom) for control features for the camera.
However, the ptz driver was not available for the current version of Stage simulation, so the robots within the simulation environment could only look straight forward.
Physical robots:
For a substantial portion of the summer, the hardware parts for the sensor plane were not available.
This caused a delay in the number of robots that we were able to test with, and that became a huge problem for things like obstacle avoidance, which we wanted to run on multiple robots.
However, most of the hardware sources became ready recently and we now have had three robots to test with!
Getting back to the updates on development of those two tasks:
Line following:
Since about two weeks ago, we started to test our algorithm using thin black tapes.
We drew arbitrary paths and turns in order to see the strengths and weaknesses of our code.
For slow speeds (up to about 0.4 m/s), our implementation works fantastic!
We did have a problem with sharp turns, where our robots were not able to track the lines fast enough and would lose the lines.
Replacing the thin tapes with thicker tapes may have helped, but this may be the fact that turns are no longer as abrupt as they were when the tape was thin.
There is definitely more room for this task to grow and to improve, such as making use of the ptz driver in the future.
Obstacle avoidance:
You might remember that I talked about an already developed algorithm called VFH.
VFH was embedded as a player driver, but it expected a solid destination point, which our subsumption system does not support (only collects instantaneous velocity and turn angle).
The VFH driver was also difficult to turn on and off within our code, which lost our desired modularity for using tasks only of high priorities.
The software guys and I eventually decided that we should borrow the ideas of VFH and to write a mimic algorithm within our code, so it can be easily fit into subsumption.
Our current code works pretty well, but more tests can be done in our next stage in order to fortify the effectiveness of our code for multiple robots.
Plotting efficiency of my research v. time:
This is a plot of a quanticized data for my research effiency this summer.
The first few weeks were not very productive, because most of my time was spent on becoming familiar with Player/Stage with its installation, simulation, and control/configuration codes.
I remember that most of our initial tasks were running simple simulations for tasks like moving in a square.
The middle of my summer became slightly more active, when we were introduced with the two tasks that would be great to add for the Proteus robots.
We started to introduce and discuss different structures and algorithms that would be apt for the tasks.
The last few weeks of the research became intensively exciting, when the hardware started to come together.
It started with simple things like the cameras coming in and were debugged and ready to go, and eventually in larger scales were the robots were starting to get built.
This was especially important for the line following task, because we were not able to test our code on simulation.
What remains to be done:
Overall, this summer was a great phase for the Pharos lab, but there still remain jobs for our team to complete.
We need to make complete documentations and demos on the tasks that we developed this summer, as well as testing it to refine our code for an even better set of robots.
I had a blast this summer, and I hope you enjoyed reading my posts. :)
-- Arthur
Subscribe to:
Posts (Atom)