I was looking for an application like “voice of sam” (I am dating myself) and found something cooler.  Several sites have voice synthesizers you can demo.  I found the Cepstral site the easiest to use and with the most options.

http://cepstral.com/demos/

You basically type in the words you want to hear, select a voice, rate, pitch, and effect and it plays.  This site also lets you save your creation to a local drive.  Cool.  So I typed in the word for a color, selected some options and WOW.  Robot voices!  They even have effects like “Old Robot” and “Dizzy Droid” and “Liquid Love”.  Making the words/voices was so easy.  The hard part is finding the right settings from so many options.

Anyway, once you save your voices to the local drive, use Wav2RSO to convert the voices into NXT sound files.  I think the NXT 2.0 software has this built in.  You can find it here.

http://bricxcc.sourceforge.net/utilities.html

Now your robot can say anything you want.

Bumpers – An example of a virtual sensor

I have a tendency to use bumpers on the front of my robots for easy (bump and escape) navigation.  Over the years I have created a couple of code sets that treat the bumper as one sensor even if I use two or more physical sensors to create it.  This article shows why and how I created a class to hide the details of a “Front Bumper” implementation.

Why create virtual sensors?

There are times when one or more physical sensors need to work as a unit on the robot.  Any combination of sensors that work as one should be considered for this treatment. 

• Readings can be taken at the same time, and used after that to make decisions for the sensor group.
• Different combinations and value readings from the sensor group can be combined into specialized output values
• Different behaviors within the same program use one common set of methods for access data.

Two Switches to Make a Front Bumper

• Two Bumpers connected to different ports – A good example is a left and right bumper pair on the front of a robot.

In this case, the programmer may be concerned about a bump on the left, right or both.  Most programs set up routines for reading the left and right bumpers separately.  This works in most cases, but does introduce some problems.

• The sensors are read sequentially, so they are not processed at the same time which could lead to problems when programming correct actions.
• The sensors are usually read in the same order, so the robot has a tendency to respond to the first positive hit and forget the second.
• It is difficult to analyze when both bumpers are triggered.  Is this a state that is interesting?  It might be.
• The programmer needs to understand the bumper implementation (normally-open/closed) and account for this in programs.
• There is little code reuse.  The programmer needs to reinvent the process for each robot.

In the case of the “two bumpers/ two sensor port” scenario, I created a class that can be instantiated within a program that provides simple, easy to use methods.  It hides the raw data and implementation.  Here are the methods:

1 TwoBumper(_cls, r, l, rtyp, ltyp);                   //CREATES A NEW TWO BUMPER CLASS
2 void TwoBumper_Read(clsTwoBumper &_bumper);          //READS SENSOR VALUES
3 bool TwoBumper_isBumpedRight(clsTwoBumper &_bumper); //RETURNS IF RIGHT IS TRIGGERED
4 bool TwoBumper_isBumpedLeft(clsTwoBumper &_bumper);  //RETURNS IF LEFT IS TRIGGERED
5 bool TwoBumper_isBumpedBoth(clsTwoBumper &_bumper);  //RETURNS IF BOTH ARE TRIGGERED

The class is created with TwoBumper(..).  The Read() method takes readings from both switches, and sets values internally for use later when the values are retrieved.  The rest of the methods are very self explanatory.  They are used to retrieve the state of the TwoBumper virtual sensor.

Here is the sample code: TwoBumper.zip – Sample program and class file for a Two Bumper Virtual Sensor

My Framework Code

Thank you for your patience.

RobotC Behavior-Based Framework for Autonomous Robots 2.2

Other links on the site have not been corrected yet.  Sorry for the inconvenience.

Some of the features for 3.0 include:

• Robot behaviors collection in one place with a core set of methods to operation on them.
  • Adding behaviors is easier now.  Just update the Behaviors list and it will be automatically initialized in the collection.
• The arbitrator is now a class which means you can deploy more than one.  This might be useful for a robot that moves and has an arm that needs arbitration.
  • Behaviors can be assigned to an arbitrator (or not) from the robot’s behavior pool.
  • The drive module was extracted from the original arbitrator so arbitrators can be used for anything. – The 2 drive parameters were made generic in the behavior class to support this as well.

— More to come.

This code uses the MOD operator in RobotC to return the number of degrees left over after dividing by 360.  These are pretty handy functions.

 1 // Returns an angle in degrees between 0 and 359
 2 int norm_360(int deg) {
 4   return deg%360;
 5 }
 6 
 7 // Returns an angle in degrees between -180 and 179
 8 int norm_180(int deg) {
 9   return norm_360(deg + 180)-180;
10 }
11 

* Thanks Xander for the reminder about the RobotC mod operator.

Average = SUM(nSamples)/n 

I found a shortcut to all of that where an average value is maintained in the background, and a weighted percentage is applied to the newest input value and the previous average.  I am sure this method is not as accurate as averaging the last n values, but the goal is not so much precision, but reducing spikes and anomalies.  In other words, I don’t care what the actual average is; I care that the trend of values over time reduces the spikes and provides usable information to the robot with less error.

Weighted Average = New Sample * %wt + (1-%wt)*Previous Average

This class can help filter sensor data to a robot, making it react more slowly to large value changes.  Try it and let me know what you think…

You can download the code here: WeightedAverage.c

Using a Leaky Integrator allow the successive bumps to be summed in the short-term memory while at the same time leaking some bumps out of the bottom at a slower rate.  As the robot thrashes more the integrator is filled up.  This value could be used to adjust the spin angle for the robot so that the more times the robot bumps, the more it turns to get out of the corner.  As the robot escapes, the memory of the corner fades to prevent drastic actions on bumps later in its journey when it may not be stuck in a corner.

An analogy for the leaky integrator is a bucket with a drain in the side that can be opened to let some water out.  Water poured into the top fills the bucket if more water comes in than is let out the bottom.  If the water stops pouring in, eventually the level will decrease to the level of the side drain.  If too much water is poured in, the bucket will eventually have the maximum amount in it and the rest is lost over the top edges.

The RobotC code contains the class.  A sample program is commented out at the bottom.  It demonstrates instantiating the class and filling a bucket (as it tries to leak out) until the bucket is full.  Once full, the input is stopped, and the bucket drains.  Very simple, but might be useful to someone out there in Mindstorms land.

Download: LeakyIntegrator.c

Thanks in advance for your patience.
Thom

I started working on a new set of projects last week.  I have been dreaming about the Mindsensors NXTCam for a very long time and now I finally have one.  I thought I would kick this thread off by outlining some of the more obvious possibilities that are available when your robot is equipped with this FANTASTIC sensor!

I can’t wait to start building and programming.  Thank you Mindsensors!

• Sorting objects by color
• Finding a ball or balls and pursue it if it moves
• Determine distance from a known object like a ball
• Maintain a certain distance from an object
• Use colored beacons for navigation around a room
• Aim a turret at an object and track it side to side and up and down
• Sequence by object color (Ex. find a red ball, then yellow ball, etc…)
• Use the NXTCam as a range finder using a laser guide
• Create a docking station and guide the robot in by “sight”
• Follow a line, make decisions at markers, make decisions at forks and crossings

Many people have done some really cool things with the NXTCam too…  I will post some of the interesting stuff at a later date.

My first order of business is to try to understand how this sensor works and reviewing and extending a driver to make programming easier.  There is a lot of documentation to look at.  This sensor allows you to customize the firmware as well, but my initial review is that it might be best to leave that to the professionals.  We will see.

I found a reference on the net that defined some boolean functions.  I added these to may math utility libary (just in case) and tested them.

OR, AND & NOT are already implemented in RobotC, but I included them because the math and logic to get the correct answer is kind of cool. 

Let me know what you think.

(I added a couple more boolean functions to the list tonight…