Girl Geek

See movement... start rolling!

The manifest is ready, so onto recreating the first step of the Lego TriBot example "start driving as soon as you see a movement" using two motors and the ultrasonic sensor.

I first want to try this out using the Visual Programming Language that comes with Robotics Studio but has its own IDE. Using basic activities and Robotics services available on your machine you can visually create a program similar to a dataflow diagram. I will use the generic services which enable you to use the program on a different robot just by changing the manifest that is attached to the diagram.

The image above shows the first part of the program, starting with the Generic Sonar. The Distance Measurement supplied by the Generic Sonar is used as the value of the variable Distance, this is necessary for the next step, comparing the variable with 30. The documentation is currently not very clear about the units this measurement is in, but based on the reactions of NXT, I guess it is centimetres. If the distance is less than 30, power is set to the Generic Differential Drive, that's the generic service for a two motor configuration used with a left and a right wheel.

Pretty simple... but how do you get to this stage? How do you know about DistanceMeasurement and SetDrivePower?

First there is some basic IntelliSense in the VPL. For instance when you have connected the Generic Sonar to the Calculate activity and explore the properties for the Calculate activity you'll get a pop-up which tells your which data is supplied by the Generic Sonar. Moving over the list will give you some indication of the meaning of the data.

Second when you connect two activities you'll have to specify a connection and in most cases the connection data. For instance you specify the input for the Generic Differential Drive by connecting the Data activity to the Generic Differential Drive. When you make the connection (or later by right-clicking on the connection) you will be asked to specify the connection by choosing one of the operations available on the Generic Differential Drive. And if the operation takes any parameters you will be asked to specify the data connection by selecting the value supplied by the output activity (in this case the Data activity) to the parameter(s) of the input activity (in this case the Generic Differential Drive). Needless to say that by specifying the same value to the left wheel as to the right wheel the Bot will move straight ahead.

So most of the information is there when you build the diagram and as a third option there is a help file included (which in version 1.0 is included in Visual Studio, VPL only includes a basic help file) in which the generic services are documented.

By now we have a generic diagram using all generic services. Here's where the manifest comes in again... the manifest will specify on which Bot we want to run this program. The manifest is specified in the properties of the generic services, in this case the MyBot manifest is specified for the Generic Sonar and the Generic Differential Drive by selecting it from the list of available manifests.

And now we're ready to run... let's go... My Bot needs to be connected by BlueTooth to the machine running Robotics Studio and then I can run the program from the machine. The response is a bit slow sometimes, but when I get close to the "eyes" of My Bot, it starts driving... first step completed.

I have a manifest... therefore I exist...

The Robotics environment uses a manifest in which you define your Robot. This manifest basically tells what properties your robot has by defining them as services. Whether your using the Visual Programming Language (more about that later) or Visual Studio, you'll need a manifest.

To get started with the Lego stuff, I build the TriBot, one of the samples for the NXT that contains all the sensors. The TriBot is programmed (using the Mindstorms environment) to react to a movement (ultrasonic sensor), start driving (using two motors), stop when it touches a ball (contact sensor), grab the ball (using a third motor), turn around and drive until a black line is crossed (light sensor). If I want to recreate this behaviour using Robotics Studio, I'll need a manifest...

The set of examples with Robotics Studio (now 1.0 by the way) comes with a partial definition of the TriBot only using two motors and a touch sensor. Nice, but My Bot has it all... So I created a manifest for My Bot by copying and extending the default manifest. These manifests are located in the samples\Config folder of the Robotics Studio installation.

The manifest already defined the Brick, the differential drive and the touch sensor. I added the Sonar Eyes service by defining the service by specifying the config file and relating it to the Brick. In a similar way I added the Arm service, the third motor to control the arm to grab the ball. The light sensor will follow later... first things first.

Both services also needed a config file. The sonar eyes use the configuration below. Important here is the HardwareIdentifier specifying to which port on the Brick the ultrasonic sensor is attached. Port 4 is also referred to in the default bumper configuration which configures the sonar as a bumper, this configuration needs to be removed to get the sonar eyes to work properly.

The configuration for the Arm is a simple one motor configuration. In this case the motor is attached to port A on the Brick.

My Bot is alive... now onto its first steps...