LiNuXT: Linux + NXT

Since transitioning to Ubuntu Linux, I’ve continued working on my Lego NXT projects. I spent several hours figuring out how to configure my machine to write, debug, and upload code to the NXT brick. I found several sites and message board posts, each detailing a specific step in the process. I thought it would be a good idea to bring all of this information together and hopefully make it easy for anyone else who wishes to follow in my footsteps.

The entire process consists of setting up a Windows emulator (WINE), installing an IDE (BricxCC), and installing and running a communications tool between linux and the brick (Talk2NXT).

Continue reading “LiNuXT: Linux + NXT”

SLAM-5 Bot part 2: The Control Algorithm

After assembling the hardware for my SLAM (Simultaneous Localization and Mapping) robot, I set about to write the code which controls the drive motors, senses obstacles, and records the robot’s path. Lego’s NXT kit comes with a rather basic visual programming language called NXT-G. This program, which constructs programs by creating essentially flow charts, is almost counterintuitive to anyone with command line programing experience. I decided instead to use the third-party programming language called Not eXactly C (NXC) and its associated IDE, Bricx Command Center.
Continue reading “SLAM-5 Bot part 2: The Control Algorithm”

Performance Testing NXT’s Ultrasonic Range Finder

I have plans to utilize the Lego NXT system for several upcoming robotics projects. The success of these projects depends on the capabilities of the kit’s ultrasonic (US) range finder. I created a test rig with the US sensor and NXT brick and conducted several experiments in order to characterize the sensor.

Test rig: wood block, measuring tape, protractor, US sensor, NXT brick (from left to right).
Continue reading “Performance Testing NXT’s Ultrasonic Range Finder”

SLAM-5 Bot part 1: The Hardware

I recently purchased Lego’s new NXT hobbyist robotics kit. After familiarizing myself with the basic layout of the command module, available hardware and sensors, and third-party programing languages by building several single-task robots, I decided to use the NXT as a forum for my studies in SLAM robotics. As I have previously quoted, Dr. John Leonard of MIT says,

The problem of SLAM is stated as follows: starting from an initial position, a mobile robot travels through a sequence of positions and obtains a set of sensor measurements at each position. The goal is for the mobile robot to process the sensor data to produce an estimate of its position while concurrently building a map of the environment.

My goal and new perspective on the problem is to design a system which is as simple as possible. I immediately realize that much of the complication in SLAM systems lays in the timeliness with which the system processes information in real time. I know that some compromise between speed and simplicity had to be established, and in pursuing the most simple system, I am willing to sacrifice a lot in speed. So I have created what I am calling the “slam five robot”. The real acronym is S.S.S.S.S.L.A.M. which stands for “super-simple, super-slow, simultaneous localization and mapping robot”.

The system consists of three components: the physical hardware of the robot, the control algorithm which guides the hardware and sensors, and the post processing algorithm which interprets the sensor data. I begin here by describing the hardware and sensor setup.

Front view of the SLAM-5 bot, showing ultrasonic range finder and wiring for the drive motors.

Continue reading “SLAM-5 Bot part 1: The Hardware”