One option would be to simply go out and drop $$ (insert cost here – I don’t know) on a aquarium heater – but that would be too easy.  I’d rather take my $300+ extra NXT & temperature sensor and make them work for a bit. Now you ask yourself, how the heck would the NXT heat the water.  Well, that’s where dSwitch from Dexter Industries comes in. Interestingly enough, the dSwitch did not come to me with the intent of using it to heat the Aquasaurs tank. It was more like irony and good timing that I just received the dSwitch and we got the Aquasaurs going.

For a full description and pictures, visit my site at www.plastibots.com.

It’s been a while since I last made a bot.  My latest is DualGrip - NXTRover (or DG for short).  I wont go into great detail as all info (with videos) can be found at my site http://www.plastibots.com, but DG has both tracks and wheels and uses an acceleration sensor to determine when it is climbing and deploys the
drive system to angle itself to engage the rubber wheels.

NXC and BricxCC now support the new color sensor in the pre-release (aka test release) build that you can download via the following URLs:

http://bricxcc.sourceforge.net/test_release.zip

http://bricxcc.sourceforge.net/nbc/beta/nbc-1.0.1.b36.tgz

http://bricxcc.sourceforge.net/nbc/beta/nbc-1.0.1.b36.osx.tgz

Before you try to control the new color sensor using NXC or BricxCC you will need to make sure you tell the compiler that you are targetting the NXT 2.0 firmware rather than the old 1.0 firmware.  With the command line compiler you tell the compiler this using the -v switch.

nbc -v=128 myprogram.nxc

The value 128 means version 1.28 which is the firmware version number of the NXT 2.0 retail firmware.  The NXT 1.0 firmware version is 1.05 so you would use 105 with the -v switch if you want to target the 1.0 firmware.

In BricxCC all you need to do is check the “NXT 2.0 compatible firmware” option on the Compiler|NBC/NXC tab in the Preferences dialog.

There are 5 new sensor types that you use with the color sensor: SENSOR_TYPE_COLORFULL, SENSOR_TYPE_COLORRED, SENSOR_TYPE_COLORGREEN, SENSOR_TYPE_COLORBLUE, and SENSOR_TYPE_COLORNONE.  These can be used with the SetSensorType API function in order to configure the sensor port for the color sensor.  For detecting colors you normally will use the full color sensor type.  You can use the four other types to detect ambient light levels (with the COLORNONE type) or as a color lamp in red, green or blue.  If you want to use the color sensor as if it were a light sensor that came with the NXT 1.0 set you can use the COLORRED type to turn on the red lamp. 

The NXC API also has sensor port configuration functions specifically for each of these sensor type: SetSensorColorFull, SetSensorColorRed, SetSensorColorGreen, SetSensorColorBlue, and SetSensorColorNone.  Each of these functions calls SetSensorType with the appropriate sensor type constant, then calls SetSensorMode with SENSOR_MODE_RAW, and then finally calls ResetSensor to wait for the firmware to finish initializing the sensor based on the new type and mode.  Your best bet is to use one of these 5 functions whenever you need to configure the NXT to use the color sensor.

Once you’ve properly configured the port for use with the new color sensor you can read data from the sensor in a variety of ways.  The simplest way to read from the color sensor is to use the SENSOR_1, SENSOR_2, SENSOR_3, and SENSOR_4 values.  These return the color number when the sensor is configured in full color mode.  You can also read raw sensor values similar to the values you get from the light sensor using SensorRaw when you have the sensor configured as one of the non-full color types.

Direct access to the color sensor fields in the Input module IOMAP structure is provided by a few low level NXC API functions:

unsigned long ColorCalibration(const byte port, const byte pointNum, const byte colorNum);
unsigned int ColorCalLimits(const byte port, const byte pointNum);
unsigned int ColorADRaw(const byte port, const byte colorNum);
unsigned int ColorSensorRaw(const byte port, const byte colorNum);
int ColorSensorValue(const byte port, const byte colorNum);
byte ColorBoolean(const byte port, const byte colorNum);
byte ColorCalibrationState(const byte port);

There is also a low level system call function called SysColorSensorRead which takes a structure argument of type ColorSensorReadType.  The definition of this structure is shown below:

struct ColorSensorReadType {
char Result;
byte Port;
int ColorValue;
unsigned int RawArray[4];
unsigned int NormalizedArray[4];
int ScaledArray[4];
bool Invalid;
};

On input to the SysColorSensorRead function call you set the Port field to S1, S2, S3, or S4.  After the call you can read the Result field to check for errors and if no errors ocurred you can access the ColorValue field or read data from the 3 arrays.  Each array is indexed using INPUT_RED (0), INPUT_GREEN (1), INPUT_BLUE (2), or INPUT_BLANK (3).

At a higher level you can read the raw color sensor values using ReadSensorColorRaw(byte port, unsigned int & rawValues[]).  You can also read all the color sensor data using ReadSensorColorEx(byte port, int & colorValue, unsigned int & rawValues[], unsigned int & normValues[], int & scaledValues[]).

The ColorValue value returned by these functions will be one of these constants: INPUT_BLACKCOLOR, INPUT_BLUECOLOR, INPUT_GREENCOLOR, INPUT_YELLOWCOLOR, INPUT_REDCOLOR, and INPUT_WHITECOLOR (1..6, respectively). 

Hopefully this information helps you get the most out of your new LEGO color sensor with NXC and BricxCC.

Thanks to Xander Soldaat who reported a bug with using enum types as function parameter types. It turned out that you couldn’t use any user-defined named type other than structs (i.e., typedefs and enums).  That defect has been fixed in this update. 

Thanks to ToGi who reported a bug that has existed since NXC came into being.  The internal list of function names that NXC uses was not correctly handling functions with names that differ only by case.  When I added the inline strcmp function to the standard NXC API in the last test release it broke his own function called StrCmp.  Now the list considers case when checking for duplicate names.

While looking at Spiller’s Structs.nxc file this weekend I came across a comment in a struct declaration that read

//you can’t “bool A,B;”?

Yes, that has been a limitation of the syntax supported by NXC for declaring struct members until today.  I had a quick look at the code that processes a struct declaration and it was pretty easy to rework the code a bit so that you can now declare sequential struct members of the same type using a comma-separated list of member names just like you can in Standard C.

Interestingly, I was about to check in all these changes today when I decided to first try to compile Spiller’s program and found that I got many compiler errors.  Doh!  The compiler was saying a struct member type didn’t match the type of the variable I was trying to assign to it.  At first I thought it had something to do with the enum changes I made which involved parameter type handling by the compiler along with a change to a function called CheckTypeCompatibility.  Thank goodness for SVN and the Tortoise SVN tools I use on Windows. With their help I was able to track down a silly mistake on my part in the comma-separated struct member changes and fix it before I checked in the code.

http://bricxcc.sourceforge.net/test_release.zip

First, make sure you have the latest test release of BricxCC.  You can always download it from this link:

http://bricxcc.sourceforge.net/test_release.zip 

Extract the zip over your existing BricxCC installation. 

Now look in %appdata%\JoCar Consulting\BricxCC\3.3\ for a file called nxt.dat.  The actual path differs depending on the version of Windows you are running but %appdata% should expand to the right path on your computer.  Edit this file with a plain text editor such as notepad.   Look for a line something like this:

BTH::BNXT=BTH::BNXT::00:16:53:0A:75:7B::1

If there isn’t anything like that in the file then add one.  Everything to the left of the equal sign is an alias for the value to the right of the equal sign.  The alias can be anything you like.  To the right of the equal sign is a brick resource string.  The bluetooth brick resource string consists of “BTH::” followed by the name you have assigned to your NXT.  By default that is just “NXT”.  Mine happens to be called BNXT. Whatever your NXT’s name is just use that instead of BNXT.  Follow the name with a pair of colons “::”.  Then comes your NXT’s unique ID which you can see via the brick menu system by navigating to Settings|NXT Version.  The ID is at the bottom of the screen.  Here’s a screenshot from my NXT:

Separate each pair of hex digits with a single colon “:”.  My NXT’s ID is 0016530A757B.  That becomes 00:16:53:0A:75:7B as you see above.  Follow the ID with another pair of colons “::”.  Last comes the virtual serial port number that is created when you connect your NXT to the PC via Bluetooth.  Sometimes mine is 1 and other times it is 5.  The value here probably will not make any difference in whether you can connect or not.

Once you have a bluetooth brick resource string entry in nxt.dat for your NXT then you will be able to pick both the short alias and the full brick resource string from the drop-down list of Ports when you launch BricxCC.  The very first time you connect to an NXT via Bluetooth you’ll have to confirm the PIN on the NXT.  Be sure to pay attention to it prompting you to confirm the PIN number.  It takes a little while for the connection to be made but afterward communication between the NXT and BricxCC via Bluetooth should be pretty quick.  Also make sure that you check the option in the Preferences dialog to use the internal NBC/NXC compiler.  Otherwise compiling and downloading programs will be way too slow.

Users of NBC/NXC or any of my NXT utilities on Mac OS X or Linux platforms can also communicate with their NXT via Bluetooth.  The nxt.dat file on non-Windows platforms lives in the Home directory (~/nxt.dat).

http://bricxcc.sourceforge.net/test_release.zip

The biggest change is support for enums.  At the moment NXC does not enforce types on enums so you can define a variable of an enum named type and then assign to that variable any integer value rather than only enumerations that are a member of the named enum type.

http://bricxcc.svn.sourceforge.net/viewvc/bricxcc/tests/enums.nxc?revision=264

I fixed a bug with unsigned values in a return statement.  I also added a slew of stdio.h, string.h, and ctype.h functions to the NXC API.  Here are a couple sample programs. The first one shows some of the new functions from string.h:

http://bricxcc.svn.sourceforge.net/viewvc/bricxcc/tests/strings.nxc?revision=264

This next program demonstrates how to use several functions from stdio.h:

http://bricxcc.svn.sourceforge.net/viewvc/bricxcc/tests/fileio.nxc?revision=269

The fseek, rewind, and all the printf-like functions require the enhanced NBC/NXC firmware. Make sure that you configure your compiler options to target version 1.28 or later of the enhanced firmware (aka NXT 2.0 compatible).

A while ago someone on the nxtasy forums reported problems with the FileSeek operation that I added to the enhanced firmware. Based on my testing this evening, it looks like the problem was with using the LDR_CMD_FILESEEKSTART constants as the origin. The LDR_CMD_* constants are not the right numeric values to use as the seek origin. Instead, use the SEEK_SET, SEEK_CUR, and SEEK_END constants (0, 1, and 2) that are included in the API as of tonights update.

LabVIEW Education Edition,

http://digital.ni.com/worldwide/bwcontent.nsf/web/all/D281AF3F29196D83862576470065AE02

the best stuff I’ve ever worked with in the context of LEGO robotics. The features are so fantastic that we have succeeded with few efforts in implementing a Kalman filter to our infrared/ultrasonic indoor GPS system for the 2D-positioning. The very first tests are very rudimentary, but all this is extremely promising.

Note also that the latest 3D sound localization robot also has been programmed with the brand-new software.

http://www.convict.lu/Jeunes/RoboticsIntro.htm

 As you probably have noticed, the forums were down for the last few days.  From what I can gather the ISP hosting nxtasy.org, aplus.net, has recently been sold to a new owner.  As part of the sale, sites hosted on a shared server are all being “upgraded” to a new datacenter in Florida.  There are messages from many disgruntled aplus.net customers who have experienced numerous problems as a result of this move.

http://forum.aplus.net/showthread.php?t=481

“Aplus.net is currently upgrading customers to an enhanced hosting platform which will allow you to take advantage of a variety of new services over the coming months. The upgrade is over halfway complete and has been successful overall.”

“As with any platform change there have been a few bumps along the road though. If you are experiencing account problems during this process, we would like to apologize for any inconvenience this may have caused you.”

“We recognize that many of you use this forum to express your frustrations. However, due to privacy concerns we will no longer address account issues on the Aplus.net forum. If you need additional account assistance, please email escalations.support@cs.aplus.net and a member of the Aplus.net escalations team will follow up with you.”

I began a series of strongly-worded emails with the above email address on Monday.  Yesterday evening I finally received a response.

“Good evening, I’m the Escalation Manager for Aplus.net and will be taking over your issue from support to make sure we have our migration team take a look into this tomorrow.  Since it’s the holiday we will email you updates unless your request otherwise.  Our teams will be working tomorrow so we’ll get you an update throughout the day as soon as we have it.”

As of Thursday, 11/26/2009, at 6pm CST the forums are back up and running again. Hopefully aplus.net will get their act together and avoid breaking them again as they continue their “upgrade” process.

John Hansen

I am sure I am not the only one who has run out of sensor ports before on their NXT.  Well now you need not worry about that problem anymore.  HiTechnic brought out their long-awaited Sensor MUX today.  It’s not just a port splitter but it also takes care of polling the sensors for you, so it will work with I2C and analogue sensors.  You can have up to 4 of these SMUXs connected to your NXT in all.  The following sensors are currently supported:

• Analogue (EOPD, light sensor, gyroscope, sound sensor)
• Lego Ultra Sonic Sensor
• HiTechnic Compass Sensor
• HiTechnic Colour Sensor, both the new and the old one
• HiTechnic Accelerometer Sensor
• HiTechnic IR Seeker Sensor, both the new and the old one

I’ve had the pleasure of owning one of these beauties for a few months now, so I could work on a ROBOTC driver for them.  I will be releasing a new version of my suite later today, so keep an eye out on the project page.

It would allow you to use your PF remotes to control your NXT motors in a very precise way.  How about a robot that won’t run into a wall, even if you accidentally steer it towards one?  I’ll be building mine into the holonomic drive robot I’m currently working on to allow manual control for demoing purposes.  I can’t wait to get my hands on it!