Generation Robots markets and sells autonomous programmable robots, which means that it is possible to program the robot’s behaviour to vary on the basis of the data that it perceives within its environment, and that the code for this behaviour is located on the robot itself (hence “autonomous”). There are also robots on the market that are not autonomous but that are controllable, for example via radio control or some other means of connection.
This article introduces a simple autonomous robot that communicates some of the data it perceives to a PC, in such a way as to make it possible to build an interface on the PC that displays the robot’s measurements in real time.
The article presented here is based on a Lego Mindstorms NXT robot and on a program code on a PC produced using Microsoft Visual Programming Language, visual robot programming interface included in Microsoft Robotics Developper Studio.
The purpose of this simple example is to show how a Lego Mindstorms NXT robot using its own development language can be autonomous (in this case, moving around an environment taking contact and distance measurements using an ultrasonic sensor), and communicate with a PC over a Bluetooth connection.
This article uses two graphical programming environments, so it is not necessary to know much about robot programming and more specificaly Lego Mindstorms NXT programming. If you wish to take things further, it is possible to generate C# code by Visual Programming Language, the robotics programming environment used for the program running on the PC.
Before starting, the reader should be familiar with the broad principles of NXT-G, the graphics development environment supplied by Lego, and Microsoft Robotics Developper Studio.To find out more, you can visit the Generation Robots website, which offers articles introducing these programming environments.
The following is a simplified diagram of programming a NXT robot, described in this article.

The source code for the programs used is available here
A very simple NXT robot was built using the Lego Mindstorms NXT kit. It comprises two servo motors connected to inputs A and C on the intelligent brick, each managing one wheel (differential drive principle), and a third servo motor driving horizontal rotation of the ultrasonic sensor (input B). This ultrasonic senor, connected to the intelligent brick’s port no. 1, takes distance measurements (in centimetres). A touch sensor is located under the robot, connected to port no. 2.
Your Lego Mindstorms NXT robot does not necessarily have to be the same shape; it is sufficiently straightforward for a vast array of different robots to be used.
Let’s first of all start with the NXT-G code, as this is the code that will be run on the Lego Mindstorms NXT robot. The diagram below shows the code produced.

The NXT-G code shown above comprises two branches, which are run in parallel on the Lego Mindstorms NXT robot. The upper branch handles the NXT robot’s behaviour. The first block controls the two motors assigned to moving the NXT robot, and instructs them to run at the same speed so that the NXT robot moves forward in a straight line. Next, two IF conditions are triggered if the touch sensor is activated (first test), or if the ultrasonic distance sensor detects an obstacle closer than 20 centimetres. The conditions are in an infinite loop so that the NXT robot continues to move forward indefinitely.
When one of the sensors in the IF switches is activated, a custom block named “Reroute” is called. We have in fact opted to separate this code within a custom block in order to tweak it. The following figure shows the code in this NXT-G custom block.

The principle behind this NXT-G block is relatively straightforward. It has to stop the NXT robot, and first of all pivot the ultrasonic distance sensor to the right. If the sensor detects no obstacle on the right, then the NXT robot heads right, otherwise it pivots the ultrasonic sensor to the left and heads left. This is not a particularly optimised or efficient space-finding algorithm, but that is irrelevant here. During each stage in this code, special text is displayed on the Lego Mindstorms NXT robot screen.
Let’s return to the first piece of code (see first diagram above). The second branch of this program is tasked with generating a Bluetooth message containing the most up-to-date measurement taken by the ultrasonic sensor in centimetres every two seconds. The Bluetooth messages generated by a Lego Mindstorms NXT robot are stored in the robot in a mailbox (a sort of queue), and the Visual Programming Language code (which we will look at later and which runs on the PC) will be tasked with retrieving the contents of this message. Note that the distance measured is converted into text before being included in the Bluetooth message. We have in fact found that the VPL code was failing to interpret the data when it was passed over in numeric format in the NXT-G block.
The obstacle avoidance code (Evitemment d’obstacle.rbt on the diagram) is compiled and downloaded onto the robot from the NXT-G programming interface (see the NXT-G guide). The rerouting custom block is automatically compiled and transferred with the previous code.
VPL code (Visual Programming Language) runs on the PC and communicates with the NXT robot via a Bluetooth connection. A future article will more fully describe Bluetooth connections with programmable NXT robots. The VPL paradigm is based on the concept of services running in a DSS (Decentralised Software Services) node, which itself sits on top of the CCR (Concurrency and Coordination Runtime) library. These two libraries, responsible for the synchronous parallel execution of robotics programs, were created by Microsoft and are included in Microsoft Robotics Developer Studio. To find out more about Microsoft Robotics Developper Studio, blocks, you can read the relevant article on the Generation Robots.

As we were saying, VPL is based on the concept of services. In the code shown above, we are using two services that are specific to Lego Mindstorms NXT. The first is called Lego NXT Brick V2 (V2 because it is the second version of the NXT services that first appeared in the previous version of Microsoft Robotics Developer Studio). This service provides the connection to the robot via Bluetooth. An important parameter in this service is the Bluetooth communication COM port, which has to be set properly (when you configure a Bluetooth connection, this is established on a COM port that has to be carried over into the service parameters).
The second NXT service is LegoBrickIOv2, which allows queries on the intelligent brick, notably for exchanging Bluetooth messages.
The principle behind the program is relatively straightforward. Every two seconds, the program will check whether any Bluetooth messages are available in the NXT robot’s first mailbox, and if this is the case it displays the contents in the dialogue box on the PC. A simple error handler is used to keep the program running when no message is found.
The nub of what we wish to show here is therefore found in the LegoBrickIOv2 service. This service, in real time, while the NXT robot is running an autonomous movement program, is used to retrieve data (in this case, the distance measured in centimetres by the ultrasonic sensor). The use made of this value is admittedly limited here to a simple display, but we could very easily imagine more meaningful uses in more sophisticated versions of this program.
The obstacle avoidance code needs to be activated manually on the NXT robot and the VPL code then run on the computer in order for it all to work.
The principles established here are straightforward. The purpose is merely to show the basics of communication between two devices (a PC and a NXT robot) and, more importantly, to explain which program works on what. In a more advanced version of the program, we could:
In conclusion, we can say that the use of graphical environments is of particular help with program development in robotics for several reasons. First of all, it avoids becoming embroiled in various development languages and the connections between them; it should be noted that robotics is not (yet?) as unified in terms of environments or operating systems as the rest of the computer world. Secondly, the development environments on offer completely do away with the whole difficulty of asynchronous parallel programming, typical of robotics development. Lastly, the libraries on offer make it possible to quickly prototype a program and to focus on the general algorithm without being hampered by technical issues such as the Bluetooth connection, queue management or parallel programming.
Generation Robots (http://www.generationrobots.co.uk)
–
All use and reproduction subject to explicit prior authorization.