Vito Cassisi – Tech Blog Delving into technology

Building a robot: A worklog – Part 3

Tactics!

Before delving into the software and physical development of BOB++, it's important to get a good idea of the tactics that the robot will perform. Making a sumo bot involves many behaviours which are critical when encountering a dynamic opponent. This worklog encompasses the behaviours which will eventually be implemented using LeJOS and Java Integrated Development Environment (IDE) Eclipse.

Note: You can find the previous worklog here.

The Static Environment
As we know, all battles are held within a small ring. This nature of the ring is known well in advance, which provides a point of reference when developing the robots behaviours. The rules of the battle are also used to determine what actions the robot can, can't and should take. These factors are always considered when creating a behaviour.

The Dynamic Environment
The opponent robot will behave unpredictably, unless you design your robot to find patterns in behaviour. Since prediction is very difficult to implement, it is wise to design a robot to act on events as they occur. These events are many and varied, and it can become tempting to scheme up elaborate solutions to specific situations. The most effective way to design behaviours is to think about the core functions that the robot will need to compete, and how they can be implemented. Once you have a functional robot, elaborate algorithms may be warranted. That being said, the best approach is to keep things simple, and to prioritise the behaviours you wish to develop. For instance, 'seeking the opponent' is of a much higher priority than 'rip their wheels off'.

So, what will BOB++ do?
After some thought, I've decided on a few core behaviours. I've created the following list, however I may alter them later if required.

Seek
The seek behaviour is insanely trivial, but will provide the basis for navigation in BOB++. When an object isn't in sight (according to the ultrasonic sensor), the two drive servos will rotate in opposite directions. This will cause the robot to rotate on the spot. If an object is detected, the EMF breaks are applied to stop the robot as accurately as possible. It will then move toward the object. If the robot loses sight of the object, then it will rotate again - rinse and repeat.

Lift main weapon
If you look back to the last prototype, you would have noticed the main weapon - a lifting device. This weapon is used to (hopefully) lift the opponent partially or completely off the ground. Doing this will make it easier to remove from the ring.
This behaviour dictates when to lift the main weapon. If an object is detected within 10cm of the robot, the main weapon will raise. The 'seek' behaviour will still be running, so the robot will be moving forward at the same time. If the robot loses sight of the object, or the edge of the ring is detected (via the light sensors), the lift will lower again.

Edge tracking
Tracking the edge of the ring is essential when competing. Even when running solo, it is difficult to keep an autonomous robot within the small bounds of the ring. Detecting the edge allows BOB++ to act immediately when leaving the ring.
The edge tracking behaviour of BOB++ will immediately halt BOB++ on detection of a black line. If the weapon is up, it will be lowered immediately. The robot will then reverse a distance of 15 cm. The 'Seek' and 'Lift weapon' behaviours may take over during the reversal.

Disorientation correction
Due to the nature of BOB++'s weapon, it is possible that BOB++ may start to flip if attempting to carry an excessively heavy load. For the reason, a touch sensor will be fitted to the rear of the robot. When the robot is firmly on the ground, the touch sensor will be pushed by the weight of the robot on the rear wheel. If the robot starts to lift, the touch sensor will release, and the robot will be alerted.
When the touch sensor reports false, i.e. it's not being pushed down, the main weapon will lower in an attempt to reorientate the robot.

These are the only behaviours I'll be implementing at first. The current prototype hardware design facilitates the above, apart from 'disorientation correction'. Fortunately, this behaviour is not necessary to compete, thus can be assigned a lower priority.
In the next worklog, I'll be implementing the seek and attack behaviours using Java and Eclipse.