ROBOTC.net Blog  

ROBOTC News

Archive for March, 2012

Using Fischertechnik Sensors with the VEX Cortex

with one comment

The VEX Cortex is an incredibly powerful and versatile microcontroller. Part of what makes it so versatile is the basic 3-pin system (Power, Signal, Ground) it uses for inputs and outputs.

When coupled with a powerful programming language like ROBOTC, the VEX Cortex allows you to connect all types of third-party sensors (and actuators) with little or no effort. Taken from the VEX Wiki, any analog sensor can be connected to the Cortex as long as its characteristics align with the following:
- Output voltage range: 0.0 v to 5.0 v.
- Must not exceed -0.5v to +5.5v.

Likewise, any digital sensor can be directly connected to the Cortex as long as its characteristics align with the following:
- Provides 0.0 to 0.6 volts for a low and 2.5 to 5.0 volts for a high.
- Must not exceed -0.5v or +5.5v.

All of the basic Fischertechnik sensors meet these qualifying characteristics, making them perfect candidates for use with the VEX Cortex!

Analog Sensors Example: Fischertechnic Photoresistor

Based on the VEX Cortex Schematic, the SIGNAL line in the ANALOG INPUTS bank is closest to the USB Port in the center of the Cortex, with the +5 VOLTS line next, and finally the GROUND line. The Fischertechnic analog sensors only have two output pins, and we’ll be connecting them to the SIGNAL and +5V lines.

In the picture below, we used the connector pins that come with the Fischertechnik system to connect the photoresistor to male-to-male jumper cables, which can be plugged directly into the Cortex. Note that with these basic analog sensors, polarity does not matter; it only matters that you use the SIGNAL and +5V lines on the Cortex.

With the sensor properly connected, configuring it in ROBOTC is no more difficult than any of the official VEX sensors. In the Motors and Sensors Setup, on the VEX 2.0 Analog Sensors 1-8 tab, give the sensor a name and choose from Potentiometer, Light Sensor, or Line Follower for the sensor type. Any of these three types will work, as they are set up to return the raw A-to-D (Analog-to-Digital) values from the sensor. The Gyro and Accelerometer sensor types perform additional calculations on the raw sensor data, making them inappropriate choices for a basic analog sensor like the photoresistor. The VEX Light Sensor is the most similar to the Fischertechnik photoresistor, so it’s the logical choice.

The values from the photoresistor can be used in your ROBOTC programs just like any of the other sensors – using the SensorValue[] command. The ROBOTC Natural Language commands like untilLight() and untilDark() will also work!

#pragma config(Sensor, in1,    FTPhotoresistor, sensorReflection)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main()
{
while(SensorValue[FTPhotoresistor] < 2000)
{
//Code
}
}

Also, just like any of the official sensors, the value from the Fischertechnik sensors will appear in the ROBOTC Sensors Debug window!

Digital Sensors Example: Fischertechnic Touch Sensor

Unlike the photoresistor, the touch sensor has three pins and we’ll need to be careful about how we plug them into the Cortex. We’ll need to plug the pin labeled 1 into the GROUND line on the Cortex, the pin labeled 2 into the SIGNAL line, and the pin labeled 3 into the +5V line. Failure to do so can result in the sensor always reading 1, always reading 0, or having the values reversed (0 = pushed, 1 = not pushed).

Below is a picture of the sensor connected to the Cortex. Note that all three lines are used, and that the Fischertechnik connectors were again used to connect the sensor to jumper cables.

The Fischertechnik touch sensor can be configured as a Touch Sensor or Digital Input in the ROBOTC Motors and Sensors Setup window.

The values from the digital touch sensor can be accessed in ROBOTC using the SensorValue[] command, and the untilTouch(), untilRelease(), and untilBump() Natural Language commands!

#pragma config(Sensor, dgtl4,  FTTouch,        sensorDigitalIn)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main()
{
while(SensorValue[FTTouch] == 0)
{
//Code
}
}

And the Sensor Debug window will display whether the sensor is pressed in or released:

As you can see, connecting third-party sensors to the Cortex and making use of them in ROBOTC isn’t much more complicated than using any of the official sensors. Happy programming!

Written by Jesse Flot

March 27th, 2012 at 1:57 pm

ROBOTC 3.08 has been released!

with 2 comments

Hi all,

We’ve just released ROBOTC 3.08. Head on over to the download pages to download the latest version!

Update: Note that 3.06 is the same software as 3.08. There was confusion due to the pre-releases of 3.06. When users opened up 3.06′s About menu, it read version 3.08. To prevent any further confusion, we’re upping the version number from 3.06 to 3.08 to reflect that. There are no software changes.

Change log:

General:

  1. Compiler check to see if include file has been modified on disk was not flushing cached token parsing results. It now does.
  2. Ignored “this”, “new” and “typeid” as ROBOTC highlighted keywords. Not supported in ROBOTC.
  3. Eliminated a compiler warning indicating char string constants are limited to 19 characters.  This is no longer a restriction and the error / warning should not be generated.
  4. Improved NXT “move to target encoder”.
  5. Source files will be reloaded by “OnSetFocus” if the file has been modified on disk. NOTE: you cannot undo the reload — which is the same behavior as Visual Studio.
  6. Added support for “memcmp” function. Make “sensorSmallBias” visible as a intrinsic variable.
  7. Compiler error  “‘volatile’ may be ignored” was patched out as ‘volatile’ is now properly implemented.
  8. Fixed bug introduced into 3.5 where “++” or “–” operators were generating incorrect code. Code generation was for pre-increment/pre-decrement; code for postfix operators was not being generated. Bug was in compiler function “typeCheckStatement” which had a couple of new parameters added to it for 3.05. The “is this top level” boolean parameter was incorrectly defaulted to ‘true’.
  9. When variable is declared “volatile”, do not use it as a temporary to hold interim results. E.G. if “X” is volatile. in the statement “X = (Y*Z);” “Y*Z” is calculated using a temp variable and then assigned to “X”. “X” is not used as a temporay as in “X = Y” and then “X *= Z”!
  10. ubyte struct element references were not being properly converted to 16-bit values when used as target for “switch” variable and when used in “if” condition clauses. Incorrect code was generated.
  11. When new sensor was added to a standard model configuration the configuration was not being updated until a name was assigned to the sensor. The same may be true for motors. This fix corrects this bug.

Mindstorms/TETRIX:

  1. Added support for new variable to enable / disable disabling Tetrix servos when user program ends.
  2. Bottom row for “NxtDrawCircle” macro was incorrectly calculated as “Top – Diameter – 1″. Changed to correct calculation of “Top – Diameter + 1″.
  3. ‘eraseRect” function in emulator was leaving bottom row of rectangle unerased. The bit map array that stores the pixel mask to keep on bottom stripe was incorrect. The “physical robot” implementation for NXT did not have this bug.

VEX Cortex/PIC:

  1. Fixed digital sensor 4 and 10 shared interrupt. Firmware only allows one sensor to be declared that uses the shared interrupt; the other sensor, if using interrupts, will be set to “none”. VEX Firmware properly disables interrupts when a sensor is removed; it may have left the interrupts enabled.
  2. Fixed a bug that affected VEX-only RVW users where the joystick wouldn’t populate unless a LEGO License was also present.
  3. Added support for displaying motor encoder port in platforms (VEX Cortex & Arduino) that allow you to associate a encoder on a sensor port with a motor. Change default visibility of “associated sensor port containing encoder” to “visible” for VEX Cortex. Modify format of debug “upload motor infor” message to include encoder values.
  4. Fixed drift in gyro value calculation. Make “nGyroJitterRange” and “bHasSensorBiasSettings” #define parameters in “loadBuildOptions.h”. Changed bias setting for gyro from 130 to 131. Fixed some small bugs in gyro bias calculation. Introduced a “gyro jitter range” setting that ignores very small changes for gyro steady state positiion. Suppose gyro bias in 1840; they the ‘ignore jitter’ would treat values in 1837 to 1843 as if they were the steady state value.
  5. Made “getSensorRawADValue” apply to VEX Cortex and not just NXT.
  6. Added support for up to 8 VEX I2C Encoders
  7. Enabled the “nMotorEncoder” command on the Cortex Platform to access encoder values
  8. Changes in Motors and Sensors Setup and Sensor Debug window to reflect I2C encoder support
  9. Added new sample programs to demonstrate the I2C encoders

Natural Language:

  1. Added support for 3 line tracking sensors in lineTrack commands
  2. Corrected untilDark and untilLight commands for corrected sensor values
  3. Corrected encoder related commands that were incorrectly using dgtl2 instead of dgtl1

Written by Vu Nguyen

March 8th, 2012 at 4:16 pm

Posted in General News

Programming with the new VEX Integrated Encoder Modules

with one comment

ROBOTC 3.06 now includes functionality to support the new VEX Integrated Encoder Modules!

The VEX Integrated Encoder Modules (IEMs) replace the plastic caps on the backs of  2-Wire Motors (269 and 393) with quadrature encoders. Unlike the existing VEX Shaft Encoders, they connect to the Cortex Microcontroller using the I2C port and provide feedback directly from the motor (with the added benefit of not hogging up your digital ports). These encoders will allow you to identify and control how fast the motors spin, how far the robot travels, and what direction it should move.

For more information and assembly instructions for the Integrated Motor Encoder for the VEX 2-wire 393 Motor, click here.

For more information and assembly instructions for the Integrated Motor Encoder for the VEX 2-wire 269 Motor, click here.

I2C Overview

As stated above, these new encoders connect to the single I2C port on the Cortex:

Unlike the DIGITAL and ANALOG ports on the Cortex, having only one I2C port does not limit you to only one I2C device. I2C ports allow multiple devices to be connected in a manner frequently referred to as daisy-chaining:

The Integrated Encoder Modules support this by having built-in sets of input and output pins. A 4-wire cable connects the Cortex to Motor 1, another 4-wire cable connects Motor 1 to Motor 2, another 4-wire cable connects Motor 2 to Motor 3, and so on. In fact, ROBOTC 3.06 will support up to 8 devices on the single I2C port!

Programming Overview

Motors and Sensors Setup

ROBOTC has undergone substantial changes to support the new encoders. Some of the most visually noticeable changes are in the Motors and Sensors Setup. On the Motors tab, the Type drop-down box allows you to choose from the different motors available in the VEX Robotics System:

This is significant because each of the new IEMs return a different number of encoder counts per revolution. Specifically, the IEM for the 2-wire 269 motor measures 240.448 counts per revolution of the motor output shaft. The 2-wire 393 motor measures 627.2 counts per revolution of the output shaft in its default high-torque configuration and  392 counts per revolution of the output shaft in its modified high-speed configuration.

Let’s take a look at a physical robot and configure it using the Motors and Sensors Setup.

  • This robot has two 269 motors with encoders.
  • The right motor is connected on MOTOR port 1. The left motor is connected on MOTOR port 10.
  •  The encoder on the right motor is the first device plugged into the I2C port.
  • The encoder on the left motor is the second device, daisy-chained off of the right motor.

We can configure this in ROBOTC by going to the Robot > Motors and Sensors Setup menu.

On the motors tab, we can enter all of the information necessary so that it matches our physical robot:

Note that:

  • “rightMotor” was configured in port1 as a VEX 269 Motor.
  • rightMotor was “Reversed” so that positive power levels will allow the robot to move forward.
  • The “Encoder” box was checked and “I2C_1″ was chosen since it is the first device plugged in to the Cortex.
  • “leftMotor” was configured in port10 as a VEX 269 Motor.
  • The “Encoder” box was checked and “I2C_2″ was chosen since it is the second device along the daisy-chain.
  • It is not necessary that the order of your motor ports correspond with the order of the I2C ports, although doing so will reduce confusion. It is necessary that your Motors and Sensors Setup perfectly match the physical setup of your robot.

Additionally, you’ll notice that there is also a new “I2C Sensors” tab in the Motors and Sensors Setup:

The additional configuration you can do here is optional. Like existing VEX Sensors, you can use this tab to name your I2C devices and monitor their values in the Sensor Debug Window. Note that these values are the raw values – not adjusted for polarity or the “Reversed” checkbox on the Motors tab.

When you’re done configuring your motors and encoders, you can press OK to apply your changes.

Function Library

In addition to the Motors and Sensors Setup, you’ll also notice new commands available in the Function Library. Most notably, we’ve included the “nMotorEncoder[]” command.

Those of you familiar with the NXT system will be very familiar with the nMotorEncoder[] command. To those who are not, it acts very similarly to the SensorValue[] command you may be more used to. The nMotorEncoder[] command gives you read-write access the value of the encoder associated with the motor specified within the brackets.

Sample Code

For example, in the sample code below, the nMotorEncoder[] command is used to clear the values of the encoders on lines 19 and 20, and then also control the distance the robot moves in the while loop on line 23. This program will cause the robot to move forward for a specified number of encoder counts (1000), while displaying encoder values to the VEX LCD.

#pragma config(I2C_Usage, I2C1, i2cSensors)
#pragma config(Sensor, I2C_1,     rightIEM,             sensorQuadEncoderOnI2CPort,        , AutoAssign)
#pragma config(Sensor, I2C_2,     leftIEM,                 sensorQuadEncoderOnI2CPort,        , AutoAssign)
#pragma config(Motor,     port1,                        rightMotor,         tmotorVex269, openLoop, reversed, encoder, encoderPort, I2C_1, 1000)
#pragma config(Motor,     port10,                    leftMotor,         tmotorVex269, openLoop, encoder, encoderPort, I2C_2, 1000)
//*!!Code automatically generated by 'ROBOTC' configuration wizard                             !!*//

task main
{
wait1Msec(2000);

//Setup the VEX LCD for displaying encoder values
clearLCDLine(0);
clearLCDLine(1);
displayLCDString(0, 0, "R: ");
displayLCDString(1, 0, "L: ");

//Clear the encoders associated with the left and right motors
nMotorEncoder[rightMotor] = 0;
nMotorEncoder[leftMotor] = 0;

//While less than 1000 encoder counts of the right motor
while(nMotorEncoder[rightMotor] < 1000)
{
//Display the right and left motor encoder values
displayLCDNumber(0, 3, nMotorEncoder[rightMotor], 6);
displayLCDNumber(1, 3, nMotorEncoder[leftMotor], 6);
//Move forward at half power
motor[rightMotor] = 63;
motor[leftMotor]    = 63;
}
}

You can see the code running on an the robot here:

For a more detailed explanation of how this code and encoders work, you should check out the videos in the  Movement > Shaft Encoders section of the VEX Cortex Video Trainer. For more information on the nMotorEncoder[] command and how it is used in the NXT system, check out this video.

Motors Debug Window

Yet another change in ROBOTC to support the new encoders was made in the Motors debug window, found by going to Robot > Debug Windows > Motors. ROBOTC will now display the Type of motor you have connected and the Encoder value as your robot runs.

This window, unlike the Sensor Debug window, will take the motor “Reversed” setting and polarity into account; positive motor powers will always result in positive encoder values and negative motor powers will always result in negative encoder values. In other words, the Encoder column displays the same value that gets returned by the nMotorEncoder[] command.

Conclusion and Future Development

The new VEX Integrated Encoder Modules are a fantastic addition to the VEX Robotics System, which we’re thrilled to support in ROBOTC. That being the case, we have additional improvements with the encoders coming down the pipeline. With integrated encoders, we’ll be able to implement “Encoder Targets” and “PID Control” like we have available for the NXT Platform. With Encoder Targets, you’ll be able to specify a “target” encoder value for the motors to spin to, and the robot will actually slow to a stop at that value, rather than letting its momentum carry it too far. With PID, we’ll be able to use feedback from the encoders to constantly adjust the power levels of the motors so that their physical performance matches what you set in the code – all with no extra effort on your part! Again for lots of additional information on both Encoder Targets and PID Control, check out the Movement > Improved Movement section of Teaching ROBOTC for Mindstorms.

Finally, if the VEX IEM’s seem like something you’d like to have (and they should) you can purchase them for the 2-wire 393 Motors here, and the 2-wire 269 Motors here.

Written by Jesse Flot

March 7th, 2012 at 4:42 pm

Posted in General News,PIC,VEX