Proteus research update

Hi all!

A good half of my research experience here at EURECA has quickly gone by, and I wanted to give an update on how the project is going along.
There were two main tasks that I am supposed to help with for the robots this summer (using the subsumption technique I described in the last post):

1. Line following using a camera (the driver is called CMUCAM2), which will greatly enhance the flexibility of the robot's motion tasks.
2. Obstacle avoidance using a method called VFH (vector field histogram), extending them to multiple robots.

The main software algorithms have been written for the two tasks, and in the past few days we were able to use the programs on the actual robots.
There will be a couple of fine-tuning (redesigning of the algorithms, if necessary) in order to make the tasks as flexible and smooth as possible.
I plan to do this within the next few weeks along with the other software research students, and hopefully we can realize these enhancement ideas well!

One of the biggest drawbacks of the recent experiments that the software students and I were doing were the clashes between simulation and true experimentation.
For example, there were some algorithms that we thought of that worked fairly well on simulation well, but not well on the actual robots.
In order to overcome this setback (that I think is universal), we need to also think of a better way to debug or observe the robot's behavior.

It would be fantastic if these useful features of the robots can be implemented within the next few weeks!

--Arthur

Proteus and subsumption

Hi all!

So, as I said last week, I am continuing to work with the Proteus robot model and its task development using what's called the subsumption technique.

A general description of the Proteus model, its foundation and research purpose can be read here:
http://frisbee.ece.utexas.edu/svn/pctb/proteus/doc/Tech_paper/Proteus_tech.pdf
(user:anon pass:anon)
The document talks about Proteus's aim to be a robot that is low-powered and easy to use; in order to achieve these goals, developers must allow flexibility in all architectural, hardware, and software design.
One of the things that allow such a simple usage of robots are the Linux supported programs called Player and Stage, allowing software developers to implement tasks through high level driver commands using the API (Application Programming Interfaces) in the programs' core library.
More information about this user friendly application can be found here:
http://playerstage.sourceforge.net/

One of the challenges that come in any design is its engineering structure.
In the Proteus's software scope, this would be the realization of multi-tasked robots; in order to achieve the flexibility that the project calls for, there needs to be a way to appropriately execute tasks that are easily layered and integrated.
This can be done through division of tasks in small modular codes which are controlled through a main program with an associated priority level.
For example, if a robot was to reach a certain destination while avoiding any obstacles, the subsumption layer would look like this:
### Highest priority
Avoid obstacles
Move to
Stop
### Lowest priority

The following article explains some insights on the realization of such robots:
http://people.csail.mit.edu/brooks/papers/representation.pdf the hi

Looking at all of these aspects, some solid goals for the summer for the robot are multi-robot obstacle avoidance and line following (using a camera).
These are implemented using subsumption in C++ codes that Player supports.
I hope to understand these engineering techniques and to dig deeper in order to help out with lower level driver implementations, as well as seek higher in order to develop high level robotic controls.

=== our current model of the Proteus robot ===
Neat, huh. :)
I hope everyone has a great Independence Holiday, I know I will!

-- Arthur