My project was to implement a remote controlled treasure hunt game. The goal of the game was to collect the largest number of treasures given a fixed period of time by grabbing and dropping the treasures on the colored paper that matched the color of the treasure. The core of the implementation was to realize a duplex Bluetooth communication link between the controller NXT brick and the robot NXT brick.
The project required the use of four NXT bricks; two to serve as master bricks or remote controls and the other two as slave bricks or drones for the hunt. The master bricks read bytes from an NXT numeric pad and transmitted the values read via Bluetooth. I obtained the code for reading from the numeric pad from the sample code in the RobotC IDE and converted the values read into function calls. That was implemented using a switch case. The remotes for the treasure hunt comprised of an NXT brick and an NXT numeric pad connected via a cable. During the early stages of my project, I realized that the structure of a Tribot (regular blueprint for building robots for tasks that require grabbing) was inefficient in it’s grabbing and holding mechanisms. To solve this problem, I constructed a castor bot. The castor bot’s grabbing mechanisms featured a motor turned horizontally. This implied direct control over the claws as opposed to the vertically inclined third motor of the tribot that required gears. However, the gears of the tribot would sometimes slip or rub against each other and render the claw moving mechanism useless. Figure 1 shows the first remote control and robot constructed as part of the testing process.
Figure 1. Controller 1 and Drone 1
To allow the robots sense the color of the treasure items and the color of dropping zones, each robot was fitted with two color sensors. One attached horizontally to detect the color of imminent treasures. The other was attached vertically, to detect the color of dropping zones. Figure 2 shows a horizontally attached color sensor.
Figure 2. Horizontal Color Sensor
From the paragraphs above, the components required for this project were, two NXT bricks for remote controls, two NXT bricks for drones used in gathering and four color sensors (two for each drone) to detect treasures. The treasures consisted of bottles wrapped in colored paper. During the implementation and testing phase, I noticed a flaw that Dr. Korsah re-established or also drew my attention to. The drones moved at a power of approximately 30 and thus would lead to a very slow game. To counter this finding, I implemented a method and initialized two attributes in the code that was to run on the drone brick. These attributes were gear and power. The gear attribute was merely an integer that stored the values 1 to 4 depending on the motor power and the rotation realized. The power attribute was an integer that stored values 30 to 100. To achieve acceleration, I read the encoder values of one of the motors during a call to the accelerate function and depending on the value, gear and power would either increase or decrease. The result was a drone that increased in acceleration after a meter of movement. Furthermore, to make the game more interactive and interesting, I ensured that all readings made on the drone robot were sent back to the controller. This included speed or acceleration and colors from the color sensors. This allowed a player to move and pick objects without having to pay too much attention to the color of the object being picked. To ascertain who wins at the end of the given time period, a counting algorithm was implemented on the drone and the results sent back to the master for viewing. The counting algorithm was built on the idea that if the color of the treasure item matched that of the dropping zone, the corresponding color count should increase by one. This made the game fun and meant a player didn’t have to manually count the number of items he or she collected at the end of the game.
The section above highlighted one of the flaws I noticed in the implementation during the test stages. Subsequently, the Bluetooth communication or messaging algorithm presented another flaw I did not see coming. I could only send messages in one direction, from the master to the slave (controller to drone). After a day of two of further experimenting with the code, I had a breakthrough and was able to send the gear value from the drone to the controller and have it displayed. This gave me a sense of fulfillment. However, prior to that, building the castor bot proved more tiring than I thought, mainly due to the fact that the bot required pieces that our kit did not posses. This meant having to look for the pieces used in the online blueprint I found. Difficult!
Working on this project was fun and educative. The remote controlled robots reminded me of my younger days and how much I desired to own one. I now know I could’ve built my own. The educational aspect of the project was inspired by the possibilities of expanding this project. I thought about tele-operated robots, a topic I presented on a week or two before beginning work on my project. I thought about the impact tele-operated tractors will make on farms in Berekuso and what tele-operated medicinal robots would make on remote medicine in Africa. Endless. I’m glad I worked on this project.