Date: 2010-12-16 Thu
Attendances: Carsten, Dan
Duration: 9:15 - 16:00
Continuing project
Fixing Bluetooth trouble
Getting bluetooth communication working in our current code
framework. We fixed it by sending too long strings to force read() to
stop.
Bluetooth working with 2 robots
Behaviors
3 modes
- Hunt: Killing other robots.
- Uses distance sensor to detect how close to other robots.
- If close enough, kills the other robot.
- Cannot find food when in this mode (light sensor doesn't register
it). - Light sensor still need to detect border.
- Increase hunger.
- Search: Searching for food.
- Sonic sensor not used.
- Uses light sensor to detect food.
- Increase hunger.
- Eat: Eating food.
- In this mode after having found food.
- Stands still and eats.
- Decrease hunger.
- Avoid: Don't move outside the level.
- Simple sequence of moving backwards and turning around.
Personality
A robots personality is defined by:
- Hunting Motivation: This determines how hungry the robot will get
before stop hunting and start searching for food. - Eating Motivation: This determines how much the robot eats after
having found a food-source.
Initial test
Our initial test with 1 robot and no avoidance gave some interesting
results. First of all, the robot moved way too fast. We need to have
the robots move as slow as possible to be able to see what they are
doing. Also, our initial guess at a personality gave a good mix of
hunting, searching and eating. It would hunt for a while, then god
hungry and go into search mode. And when finding something to eat it
would stay a eat for a good while before going back to hunting.
sensor reading interval
Our robot has a step-count of 0.5 seconds, this indicate when to
increase hunger. But 0.5 seconds is enough time for the robot to move
over a border or food without behaviors acting on it. So we simulated
concurrency with a busy-wait. We sleep 10 ms at a time and each time
check if a border or some food is detected. If detected the 0.5
seconds sleep is interrupted.
The reason this works is that only search and hunt can be
interrupted. And neither of those use any waiting. They just choose
new speed settings for the wheels. But avoid and eat do use
thread.sleep.
Track
We set up a track. A beige rectangle with gaffer's tape as an edge and
pieces of white paper signifying food.
Killing
We implemented the kill mechanics naively by checking if the distance
sensor detects something within 10 cm (or at least when the sonic
sensor returns a value less than 10). When a robot kills something it
will make a sound. It is up to the humans to detect and remove the
robot that was killed. Having a robot detect when it is killed is not
easy, and we decided to just emulate that behavior ourselves.
Track test
Our initial test with one robot with an average personality would run
around and hunt a bit. But spend most of its time searching and
eating. It stayed alive throughout the trial of 5 minutes or so. The
main problems was the robot would sometimes not detect edges properly
and run off the track, requiring help to get back. Another problem was
our pieces of paper were not taped down, causing the robot to move the
paper around confusing itself.
Personality
The PC can now transmit a new personality to a robot. This was
difficult as the NXJ doesn't report null pointer exceptions in its
threads.
