To add a new behavior control you have to perform the following steps:
- Add an agent tag in “agents.xml”.
- Add the agent’s own option to the options in “agents.xml”.
- Add an option-definition tag in “options.xml”.
- Extend the ModuleSolutionID enumeration in “SolutionRequest.h”.
- Extend the switch-statement in getModuleSolutionName() in “SolutionRequest.h”.
- Add the solution to “BehaviorControlSelecter.h”.
Dave
- Isaac -
My assigned state is the grab-ball state, in which the robot must first try to block the ball as it comes by, using 3 different blocking techniques, then approach the ball to grab it, and then return to the original position (fixed absolute position in the field for the case of the passing around challenge).
Once the detailed design was ready, the states and transitions were coded using XABSL, debuged and loaded into one of the aibos.
The first testing showed some odd behavior that was rapidly debuged, and then we could realized of the “big problem”.
The states machine designed for this task has proven to work fine with the robot, and all the states are launched at the right time. Even the blocking state works most of the times.
The main issue that has arised during the testing session is the self localization problem. Every aibo has a representation of the world, and an estimation of its current position (absolute position) on the field. If this estimation is not accurate enough, the robot will never be able to grab the ball and return to its playing circle in order to perform the next pass.
Some ideas are already over the table in order to solve this problem:
- Use longer head movements to improve self localisation after ball has been grabbed
- Use odometry to compute relative positions
- Use a referential initial position
Every mentioned solution has of course its own drawbacks. For instance, according to some odometry tests, most of the robots will turn 90º after 4 meters of straight walking, which makes impossible to rely just on odometry self positioning.
- Isaac -
As part of the challenge we are facing for the DOAS project, we must research, implement and test some behavior algorithms to fullfill the “passing challenge” that basically consists on 3 robots passing the ball to each other without leaving (or leaving as less as possible) some predefined circles.
As we like general ideas and implementations, we designed a behavior controller (a state machine) under no particular assumtions about the particularities of the passing challenge (triangle formation, number of players, size of the circle, etc) so we will be able to reuse most of the work for this challenge to implement the “fooling around challenge”.
Once the main states machine was defined, we splited the middle layer states between the group members to perform some more detailed design and implementation. As all the individual states are independent of each other, this is possible and only in the upper behavior layer they will all be joined together.
Well…. we finally got started. The DOAS projects have been launched and we have set up our goal.
We will be working with AIBO´s for the next month, developing the framework for the “Fooling Around” anb “Passing” challenges.
As a first step, we got right into the lab to get some taste of what the robots can do, and a quick look to the development environment.
The Dutch Team uses software based on the 2004 German Team software.
Soon we will be dealing with problems, compilations, testings, state machines, and a very long etc.