NXT Robotics Activity

During our first two classes, we were split into teams and given the assignment of programming a Lego NXT robot. When first told about this assignment, I must admit I felt a little nervous. After all, I had never done anything that complex with Legos in my life, and was always totally bewildered when friends of mine would talk about computers and computer programming. I’m the first to admit that technologically speaking, I’m years behind – this blog is about as advanced as I’ve gone so far.

Looking over the assignment thoroughly, my group members (Anna V. and Angela B.) and I realized that the first step toward completion of the assignment would be a speedy completion of the robot’s construction. Not to be a braggart, but I feel that our group must have had more than a little experience building Legos as kids, (I sure did) for our robot was constructed in no time. We accidentally constructed him so fast, we were attaching light sensors and sound monitors to him before we realized we didn’t need to do that for this project.

Once constructed, it was time to deal with the bulk of the assignment: the NXT programming. Having never done anything like this before, I was amazed at how simple it was to make our robot (whom we affectionately dubbed “Rover”) move around via the LabView program. With the USB cable connected to the robot, we tried out a variety of different NXT paths for Rover. First, we made him move in a straight line, then changed the power level that his wheels moved at, causing him to move at different speeds. For fun, we made him sing a little robot tune as he sped along, and then we got creative. We added the option to have Rover stop moving when we pushed his orange button, and programmed him to run without being connected to the computer via USB. After disconnecting him, we got him to run at a variety of speeds.

We realized that each one of Rover’s big wheels was controlled by a different motor, and therefore had a different port on the LabView program. Port A controlled one wheel, and Port B controlled another. By changing one of the Ports to go the opposite direction as the other, Rover began to spin in a circle, but the assignment wasn’t to get him to spin in a circle, it was to have him travel in circle with a diameter larger than two feet. To do this, we determined that we would need both wheels turning in the same direction, but at different power levels. After a few trials, we concluded that it was not what speed the wheels were at that determined the diameter of the circle so much as the difference between the power levels that was important in regards to diameter. With this in mind, we successfully got Rover to complete a circle with a diameter of two feet, all while still singing his song (a beautiful melody that sounded like a cell phone ringtone from 2000).

For the last part of the experiment, we needed to determine how accurate our measurements were versus the measurement provided by the LabView program. We used a ruler to determine how far Rover traveled at various speeds over a one second period, then used LabView to see what the program determined was the distance he traveled. For this, we needed to calculate Fractional Error, as shown by this equation:

Fractional Error = d(ruler) – d(program) / [ d(ruler) + d (program) / 2 ]

where d(ruler) is the distance measured by us, d(program) is the distance measured by LabView, and both are in meters. Here is a table of our results:

After analyzing this data, we realized that our fractional error increased as the power level increased. This did not surprise us, as it became harder to measure Rover’s distance the faster he went. At low speeds, he stayed more or less in a perfectly straight line, while at higher speeds he began to veer to the right and left. We determined that the higher his speed, the farther he would travel in a given amount of time, but less accurate our measurements were.

We finally deconstructed Rover, and though he may be gone, the lessons we learned from him will never be forgotten.