1) Convert Ringtones to RobotC code

http://tinkernology.blogspot.com/2010/07/ringtone-converter-for-robotc.html

2) Using a temperature sensor… has some great tips

http://tinkernology.blogspot.com/2010/07/ringtone-converter-for-robotc.html

3) Arduino Alternative?

http://mightor.wordpress.com/2010/06/24/the-new-arduino-alternative/

Details of the release are found here at Xanders Blog.

I’m in the processing of trying it out, and working my way through some RobotC samples. Especially for using the HiTechnic Experimenters board.

Here is the project (same exact one from the prior example).

And here is the robot with the attached sound sensor.  Please note… I’ve only put the sound sensor in this location since the robot isn’t actually driving.  If it was going to be driving, I’d probably not bother with the sound sensor.  They are notorious for picking up the sound of the motors.

This time, everything worked perfect.  The LEDs almost pulse in time to your speaking, which is a neat effect.

My son came in to see what was going on.  He near broke my eardrum trying to get a nice loud noise to spike the LEDs.  Loud claps less than 6 inches from your ear tend to hurt.

This project was a very simple one.  I didn’t have to do any debugging or tweaking, since it just worked.

Example 5 deals with a home-made light sensor.  Should be a good project for tomorrow.

Depending on the value you turn the potentiometer to, a different LED lights up.

Here is the 2nd project (completed).  The 4 LEDs are there.  The Experimenters kit ships with 2 Green and 4 Red LEDs.  So that’s why I have mixed colors.
The blue piece (above the first green LED) is the potentiometer.  You’ll want to use a small screwdriver to turn it.  It’s a fairly precise pot.  There are also 6 resistors (identical in value).  One for each LED.

BTW, here is the robot I used for these projects.  I know Brian will recognize it.  All three of my NXT’s were in use, so I just grabbed one to use.

I started playing with this one once it was built.  It seemed to work right off… except for one thing.  The last LED on the right never lit up.

So, I started debugging.  The NXT display shows the value of the pot at any given time.  So I started matching numbers up to what was in the code.

The last LED should light up if the value of the pot exceeds 511.  However, the pot never exceeds 511.  The highest I was seeing was like 508 or so.  Then it looped around into the negative.

So, I changed the code to make the last LED light up after 325.  And everything worked beautifully.

Being new to RobotC, I figured this might be a fun little mini-project (and I do mean mini) to tackle.

So, first thing I did, was start checking the functions and such in RobotC.  I found a neat value you can read.

nImmediateBatteryLevel

It returns an integer of the battery level.  If your battery level was 7.499, then this value returns 7499.

So I copied a line of code to display this value on the NXT, like this below:

nxtDisplayTextLine(1, "%d", nImmediateBatteryLevel);

Perfect!  But wasn’t quite satisfied.  I wanted to display this on the NXT with the decimal.  And a bit of text so I knew what the value was.

Well, with a bit of math, you can divide a integer by a factor of 10 to get a decimal.  Since I wanted 3 decimal places, I divided by 1000.  In order to do the division, you need to convert (or cast) the integer to a float.  So that’s where the (float) code comes in. I also found you can include plain text in the nxtDisplayTextLine() function, and it will display that.

So here is what I came up with.

nxtDisplayTextLine(1, "Battery: %.3f", (float)nImmediateBatteryLevel / 1000);

That code puts the word "Battery: 7.499" on Line 1 of the NXT screen.  The 7.499 is the actual battery value.  The %.3f means I want a value with 3 decimal places, of type Float.

For those of you with a C background, this is common knowledge.  For those with a Basic background, type conversions are usually automatically done for you.  In RobotC, you have to be explicit about it.

Here is the first project.  The red circle in the bottom right is the push button (it’s a temporary switch… you hold it down if you want the light to stay off).

The red-orange dot on the left is my LED (it was on when I took the picture).    The circuitry at the top of the breadboard is the Experimenters board.  It plugs directly into the breadboard, and has a NXT compatible jack.

I ran into a few issues with this project.  Namely… the LED wouldn’t light up.

Since I’m new to electronics, I started with step 1 in debugging.  Double and triple checking to make sure that the circuit was created properly.  Some components can be connected any way you want (like jumper wires and resistors).  Others have polarity, and can only be connected one way (like the switch and the LED).

After much checking and re-checking, everything was fine.  So my next thought, was I had a bad breadboard (It was a new board that came with the Experimenters Kit).  I swapped everything over to one of my other breadboards.  Still no light.

My next thought, was either the Experimenter Prototype board was bad, or it was the code.  Since it came from HiTechnic, and I assumed they tested everything first, I started checking code.

First thing I noticed, is that Xander wrote the tutorials for HiTechnic for this. From what little I know of Xander, I know he tested the code before it became a tutorial, so my best guess, is something changed between the version of RobotC that was originally used, and the version (2.02) I’m currently using.

The example code displayed the value for the button on the screen.  I noticed it was 0 for when the button wasn’t pushed, and –1 for when the button was pushed.

However, the code was looking to see if the value was less than 512 to turn off the LED, and if it was more than 512, it turned the LED on.

They didn’t match.  So, I just changed the code to check for less than 0.  If it’s less than 0, turn the LED on.  Otherwise, turn it off.

TADA!  Works.

I’ll dig later into why it changed the values.  I’ve had some fun today learning a few very basic electronics bits, and digging into debugging some RobotC.

I’m going to write about my adventures (and I do say adventures, since electronics is not my strong point).  I have some grand ideas to use for this Experimenters kit, but I need to master the basics first.

I’m a programmer by trade (mostly in the .NET languages) and the NXT-G graphical interface has always bugged me.  For me, it’s very foreign, since I’m used to a text based programming language.

My other choice that I looked at was leJOS.  But I’m not much of a Java guy… so I went the C route.

First impressions?  I’m liking it.

The IDE is pretty nice.   Has some decent features and works well.  Not as robust as Visual Studio .NET 2010, but that’s asking a bit much, right?

I like the debugging interaction.  I can step through my code as it runs.  Check variables, etc.  And, I can do this with Bluetooth or USB.

I plan on buying the full version soon, since my 30 days has about 2 weeks left.

Another nice feature, is that the firmware is similar in functionality on the Brick.  That means my son can run the applications already on the brick, and not have to worry about learning a new system.

Right now, I’m still learning… and looking for some good RobotC tutorials.  Haven’t found many yet.  Maybe I’ll have to start posting some samples.

The first is for a great RobotC tutorial written by professor Albert Schueller from Whitmore College.  You can read Xander’s post here, or download the RobotC Tutorial PDF directly.

Xander also writes drivers for RobotC.  He’s recently updated his project page, to show the new drivers and what they cover.  You can see the RobotC Drivers here.

And, if you are interested in using RobotC, you can purchase a license, or read more on the official RobotC website.  They do have a 30 day trial.