Vito Cassisi – Tech Blog Delving into technology

Building a robot: A worklog – Part 1

Robotics and Lego!
The term 'robotics' brings many thoughts to mind, such as 'cool', 'awesome' and 'intricate'. A robot is often seen as an intelligent biped with humanoid characteristics, which is indeed cool, but if film has said anything to us mere mortals, it's that these things are extremely complicated machines.

Considering the public perception of robotics, if you were to ask someone to help you construct a robot, the chances of them accepting would probably be influenced by their technical enthusiasm. A layperson will likely assume it's beyond their abilities, which is not necessarily the case. This is why I've started this worklog, I want to give people a look at the development of a simple robot. If anything, it'll get more people interested in robotics. :)

For the sake of intuitiveness, I'm going to be using Lego in this project. It's great for modelling physical structures, and the Mindstorms kits make the process of assembly easy. More specifically, the kits of interest are the NXT and NXT 2.0 models. I'll be working off the original NXT kit, however version 2.0 is very similar, and for the most part interchangeable with the first. Before you shout "But Lego is for 8 year olds!" I'll put things into perspective. I will only be using the NXT hardware. That is, the 'brain' of the kit, also known as the Intelligent Brick, will be re-flashed with LeJOS firmware. This allows me to program the robot in Java. For the uninitiated, Java is an object orientated programming language which is commonly used for cross-platform applications, mobile phone apps, and Internet applets. Wherever there's a Java Virtual Machine (JVM), you can run a program written in Java. This is what LeJOS provides - a compact JVM.

Note: This worklog isn't a tutorial. It's a written update of the work I'll be doing on this robot. I'll aspire to include as much information as I can to assist anyone who wishes to use it as a guide. I will be writing a separate step-by-step tutorial, and will inform readers when it's completed.

What's the robot for?
The robot is a remake of a project my UNSW ENGG1000 team and I built over a year ago. We called it BOB++ (don't ask), and its sole task was to sumo wrestle. The goal of the project was to compete in the annual ENGG1000 SumoBot competition - and win. The higher you made it up the competition ladder, the more marks you got. Without getting into too much detail, our robot was significantly hard to beat. We won 5/5 qualification rounds, before getting into the final. This match was almost called a draw due to the length of time the robots were fighting; we had almost broken the 3 minute time cap. Unfortunately, a brief slip of our drive wheel allowed the opponent to remove us from the ring. Nevertheless, in the grand final, where the three best robots were placed into the one ring, BOB++ didn't hesitate to barge both opponents out ASAP.

It was sweet revenge.

What are the rules of the competition?
Much like a traditional Sumo fight, the aim of the game is to remove the opponent from the ring. This ring is 500mm in diameter with a 15mm non-reflective black borderline. The inside of the ring is white.

During play, the following rules must be followed:
- Robots cannot fire projectiles
- Robots cannot intentionally damage their opponents
- The first robot to have more than 50% of itself outside the ring loses
- Robots must not exceed 1KG
- If a detached part of your robot is removed from the ring, you lose
- A robot must wait 3 second after being activated before moving; the match officially starts after these 3 seconds
- A robot must move within 10 seconds of the match starting, otherwise it's disqualified
- A match is a draw if 3 minutes pass without either robot winning
- The robot must be autonomous; you cannot use the inbuilt Bluetooth functionality

The initial starting positions are as follows:

How did BOB++ work?
BOB++ was built using a Lego NXT educational kit. A typical kit includes a multitude of Technic pieces, an Intelligent Brick, three servos, and a range of sensors including:

Ultrasonic sensor
Uses ultrasound to determine the distance between it and another object.

Sound sensor
Determines the decibel (dB) loudness rating of ambient sound.

Touch sensor
Basically a simple switch. It's either on or off, the former being when the button is held down.

Light sensor
Determines the intensity of ambient or active reflected light. The latter is achieved via a red LED on the sensor.

The ENGG1000 course permitted the addition of a second light sensor.

Instead of using LeJOS, we were told to use NXC, which is based off the C programming language.

The design of BOB++ was quite simple. We focused on creating a robot which was simple to build, simple to program, and highly effective. The main weapon was a lifting mechanism attached to the front of the robot. When an enemy was in range (as determined by the ultrasonic sensor), the lifting mechanism controlled by a single servo would raise. The aim was to get close enough so that we could lift the opponents drive wheels off the ground. If nothing was in range, or the edge of the ring was detected, the lift lowered itself.

During some trials, we noticed that our robot was capable of lifting itself off the ground if the opponent was heavy, or if the lift got stuck. To determine this, the touch sensor was placed near the rear of the robot so that it was always touching the ground (i.e. it was always on). If the robot starting lifting from the floor, the touch sensor would turn off, and the lift would know to release its load.

Since the ultrasonic sensor was fixed, we set the default robot movement to spin until another robot was detected, effectively giving the robot a 360 degree view. The robot would move toward the enemy on detection.

The light sensors were attached on the front and rear of the robot to help determine when we were going outside the ring. If the light sensor detected a low light value (the black line representing the ring's border), appropriate actions were taken to remain inside, as defined by our program.

Note: We did not use the sound sensor.

How can BOB++ be improved?
There are many ways the design can be improved. At this time, the main focus is to build the robot so that the following issues are addressed:

Easy access to the battery compartment
The mounting points on the Intelligent Brick are difficult to work with. Half of them are on the underside of the brick adjacent to the battery door. For this reason, it's important to make the Brick either removable, or to keep the underside unobstructed. This was a major issue with the original BOB++ robot.

Low center of mass
A lower center of mass means the robot is less suseptable of being pushed over by an opponent. Top heavy designs are easier to topple, so its a good idea to keep most of the weight near the bottom of the robot.

Structural integrity
BOB++ wasn't as strong as we would have liked. Several small changes before the competition meant there was less strength in the design. Fortunately this wasn't a problem in the competition, but it's always a good idea to have a solid design.

Enhanced behaviours
The AI in BOB++ was functional, but it had its quirks. For instance, the main weapon would forget its position on occasion, and try to raise the lift whilst its already at its highest point. Crunching of gears assured! There was also very little in the way of filtering data from the sensors. We opted to use raw data directly, which can be a problem if the sensors briefly report an erratic reading.

What's next?
That's all for now! In the next log, I'll get into building the robot and showing off my design decisions. I'll describe what I've done, and the reasoning behind it. Stay tuned!

---

Again, I apologise for leaving this blog so deserted lately. I'm trying hard to make time for posts. Thank you for visiting, though!