This is a video of my RoboHand Prototype.  The RoboHand series is literally built on the fact that my brother has only one hand (perfectly normal, no sharks or amputations involved).  The RoboHand is an NXT machine that slips onto his arm and in a way replaces his missing hand.  It isn’t perminant, but it’s interesting to work on just the same.  Not many people are able to “experiment” on their brothers   done

no brothers were harmed in the making of this film

        Lego Mindstorm NXT is a programmable robotic. The brain of the robotic is a brick-shaped computer called the NXT Intelligent Brick. All of our programs are downloaded from the computer and compiled in the brick.

We had a lot of fun building our two NXT vehicles. With Lego Robotics, you can build “humanoids”, “animals”, “machines”, or “vehicles.

     Even though we meet every day, we only meet for forty minutes of the day. It took a couple of weeks to build both robots for the club.

       Also, it is important that before you start building your robot that you organize all of your materials into the organizer Lego provides with the kit. It will help save a lot of time for you and your faciliatator!

This is a movie of my latest NXT robot, the Type bot.  Designed to type out keys on a computer, type bot uses many motors and sensors to push the individual keys.  After months of building and programing, the final version is able to type over 35 different keys, inculding space, enter and all the number keys.  It is a slow robot though, so the movie is sped-up 4x so that it’s just over a minute long.done

The NXT is a Lego robotics product that uses many special sensors to interact with it’s environment.  Touch, sound, light, and ultrasonic “eyes” are just a few of the available sensors, yet it is an easy system to use.  This movie shows some of the simpler robots I’ve built, as well as a robotics competition I visited.  If you would like to know more about the NXT, click on this link:  http://mindstorms.lego.com/eng/Overview/default.aspxdone

In my last post I did some experimenting with a low pass filter in Excel. But then there is reality. The US sensor is a slow sensor, I can’t use the sample rate I experimented with. I found out that RobotC, my programming environment, reads the US sensor about every 70 ms. This is a lot slower than the 4 ms I used in my experiment. As a result the filter responds far too slow as you can  see in the first image. FreeRover would hit a wall  ansd still be thinking it was over 20 cm away. If I increase Alpha the filter reacts faster but it will not be as effective as a filter. I needed something else.

The filter described in my last post and above is a first order filter, meaning it uses the current reading and the previous result. Second order filters also use the two previous readings. I started experimenting with a second order filter. Here is an image of the results.

Again, the red line represents raw readings, the green line is the result of a first order filter, the blue line is the result of a second order filter. Thetime axis has changed scale as I use a sample rate of once every 0,070 ms. There are five scenario’s. Scenario 1 and 3 are faulty readings of zero. Scenari 4 is a faulty reading of 255. I won’t go into much detail of these scenario’s, but notice that the second order filter is about as responsive as the first order filter but is more effective in filtering out spike errors.
Scenario 5 is the most interesting one. Here, the robot drives into a wall at a speed of 100 cm/second. This is quite fast for a robot, almost the speed of a walking man. Both filters respond with some delay, this means that the real distance to the wall is less then one might think based on filtered values. Upon hitting the wall the first order filter gives a distance of 5,5 cm, the second order gives 6,3 cm. The size of the lag can be altered by altering alpha and beta but will also depend on the speed of the robot.

I conclude that it is important to know the sensor, the kind of errors it gives and the sampling rate it can handle. It also is important to know the robot, how fast it will go. And it is important to tune the filter. This is best done in a spreadsheet at first.

Here is my code for a second order low pass filter for a US sensor.

float lowPassUS;

task SonarLowPass()
{
  // sensor reading speed
  int  deltaT=70;
  float alpha=0.2, beta=0.18;
  float US0=0,US1=0, US2=0;
  // Start main loop of the task;
  while(true)
  {
    wait1Msec(deltaT);
    // low pass value of US sensor
    US0=(float)SensorValue[sonar];
    lowPassUS=US1+alpha*(US0-US1)+beta*(US0-US2);
    US2=US1;
    US1=lowPassUS;
  }
}

Today I decided to enhance US sensor output. Why? Sometimes I had the impression the car changed behaviour. I suspected this had something to do with faulty readings from the Ultrasonic sensor. I decided to make a low pass filter for the US sensor. This should eliminate random faulty readings. But first I had to understand low pass filters. Coding a low pass filter isn’t too hard. There is an explanation on Wikipedia. Basicly it’s just one line of code:
lowPassUS=lowPassUS+alpha*(SensorValue[sonar]-lowPassUS);
The filtered value is calculated from the raw value and the previous filtered value. There is one parameter, alpha, that controls the filter. I wanted to understand how the value of alpha changes the behaviour of the filter. That is why I did some experiments in Excel. Here is an example. The red line represents unfiltered values, the green filtered values. The horizontal axis represents time. 

The alpha factor does one thing, it controls how fast the filter adjusts to a new situation. The smaller the alpha, the quicker the filter reacts. In the plot it means that the green line follows the red line more closely. The downside is that less noise is filtered out.
There is one other thing that is important to realise. Alpha doesn’t control the time the filter takes to adjust, it controls the number of steps (iterations) the filter needs to adjust. This means that there is a relation between sample rate, how often the output from the US sensor is read, and alpha. With a higher sample rate and constant alpha, the filter adjusts quicker in real time. But also, if the sample rate is changes one also needs to consider to change the alpha.

The graph above shows four scenario’s. At t=1 the sampling starts, the filter needs time to adjust. One should give the filter time to settle, or, one should initialize the filtered value to the unfiltered value.
Around t=0,3 I tested another scenario. The reading of the Sensor changes because an object is in sight. In this example it takes about 0,1 second for the filter to adjust to the new situation. Is this quick enough, for me it is.
Around t=0,46 there is an faulty reading, the filter dampens the reading but for a short time (0,06 seconds) the objects seems further than it is.  In my case, The damping needs to be enough so that the filtered value  not exceeds treshhold. I need more real life testing to find out the damping is enough. Also I do know i get faulty 255 values sometimes, but I don’t know if I also get faulty zero values. These will affect behaviour more often, as they can influence collision detection.
Around t=0,6 the last scenario is shown.  Here an object at 60 cm dissappears and and a background object at 90 cm appears. But this time the objects doesn’t dissappear at once but during a short time it is sometimes sen and at other times it is not seen. Here the filter really smoothens out the jitter.

FreeRover is an autonomous robot. This means it acts by itself without human intervention. This posts handles the way its behaviour is implemented.

First I’ll discuss what I want FreeRover to do. Then I’ll describe its sensors and actuators that are used to make it behave. Then I’ll describe the design paradigma I used to implement behaviour. After that I’ll discuss some implementation details.

FreeRover must wander around on its own avoiding obstacles on its way. If it gets into trouble (get stuck) it should be able to free itself. I also want it not to be too repetitive.

In this post I’ll simplify FreeRover a bit. This helps in understanding the behaviour of FreeRover. I will assume that there are only 3 sensors, one for obstacle detection, one to detect if it got stuck and one to find out how far it has been driving. Also, we will discuss only two actuators, one for driving and one for steering.
In reality, FreeRover is more complicated. To find out if it got stuck FreeRover combines information from a US sensor, a touch sensor, motor power consumption and the motor encoders.

As FreeRover has only one kind of behaviour – it just drives around – I choose a hierarchical control system. In this design paradigma behaviour is modelled into nodes, each node reresenting a different kind of behaviour. Only one node executes at any given time. Complex nodes can be constructed from simpler lower level nodes. In FreeRovers case there is one top level node, representing the “wander around” behaviour. Below that thee are different lower level nodes: “drive straight”, “make a corner”, and “get out of trouble”. The “get out of trouble” node consists of several “make a corner” nodes.
Each node can have input parameters that change the behaviour of the node a bit. There are two kinds of input parameters. The first kind tells the node how to behave while executing the node. Speed and steering angle are examples of this. The seconds kind of input tells a node when to finish executing, for example after driving 40 centimeters. Circumstances can prevent nodes from finishing their task. In this post I’ll only discuss one such circumstance, this is when FreeRover gets stuck. When a node finishes it returns to the parent node if it finished on the stop condition or due to circumstances.  This information is used by the parent node to select new behaviour.
Here is some pseudo code for FreeRovers behaviour.

// Top level node for behaviour
// Drive straight until close to an obstacle
// then turn until there is a free path right in front
// repeat forever
// But when got stuck, try to escape

WanderAround()
  start loop forever
    ReturnParameter=DriveStraight(until close_to_an_obstacle, forward)
    If ReturnParameter=succes then ReturnParameter=DriveCorner(until no_obstacle_close_by, someDirection, forward)
    If ReturnParameter=got_stuck then Escape()
  end loop forever

// Drive in a straight line (forward or backward)
// halt function when stop condition is met or when stuck

DriveStraight(stopCondition, direction)
  setSteeringAngle(noAngle)
  setSpeed(direction)
  loop until stopCondition
    If TestForErrors()=true then return got_stuck
  end loop
  return succes

// Drive in a circle, clockwise or counterclockwise, forward or backward
// halt function when stop condition is met or when stuck

DriveCorner(stopCondition, angle, direction)
  setSteeringAngle(angle)
  setSpeed(direction)
  loop until stopCondition
    If TestForErrors()=true then return got_stuck
  end loop
  return succes

// Try to escape from being stuck
// make a backward clockwise turn and then a forward clockwise turn
// repeat this sequence until a free path straight in front

Escape()
  loop forever
    ReturnParameter=DriveCorner(until 10 cm, toLeft, backwards)
    ReturnParameter=DriveCorner(until no_obstacle_close_by, toRight, forward)
    If returnParameter=succes then return succes
  end loop

It is amazing how only a few nodes like this can result in nice and efficient behaviour. If only I could make a proper video. But usually I work on my robot at night and then poor light conditions prevent my from making a video.

I found out that a bathroom is a good place to test robots. There is not too much rubbish in it to disturb your robot. Also, the floor is smooth and most objects in the bathroom have a hard surface and are easily detected by the US sensor.

Here is the robotC code dealing with behaviour. Please note that there is also a rest behaviour I didn’t discuss in the post.  Also the main task implements the top level node for behaviour.

typedef enumWord
{
  brcSucces   = 0,
  brcTouch    = 1,
  brcSonar    = 2,
  brcStall    = 3,
  brcStuck    = 4
} TbehaviourRC;

typedef enumWord
{
  stopOnProblem   = 0,
  stopOnSonar     = 1,
  stopOnDistance  = 2,
  stopOnButton    = 3
} TstopCondition;

typedef enumWord
{
  STrest=0,
  STdrive=1,
  STturn=2,
  STescape=3
} Tstate;

Tstate state=STrest;

/***************************************************************************************************\
*  Behaviour: goStraight                                                                            *
*  Purpose: Allow the car to go straight                                                            *
\***************************************************************************************************/

TbehaviourRC goStraight(int speed, TstopCondition condition, int stopValue)
{
  float startPoint=getDistance();
  if (speed==0)
    speed=50+random(50);
  setSteer(0);
  setSpeed(speed);
  while (true)
  {
    // check for normal termination
    switch (condition)
    {
    case stopOnSonar:
      if (SensorValue[sonar]<stopValue) return brcSucces;
      break;
    case stopOnDistance:
      if (abs(getDistance()-startPoint)>stopValue) return brcSucces;
      break;
    default:
    }

    // Check for error conditions
    if (hitSomethingNew()==true) return brcTouch;
    if (stall()) return brcStall;
    if (speed>0 && SensorValue[sonar]<10) return brcSonar;
  }
}

/***************************************************************************************************\
*  Behaviour: driveCorner                                                                           *
*  Purpose: Allow the car to drive a corner                                                         *
\***************************************************************************************************/

TbehaviourRC driveCorner(int speed, int steer, TstopCondition condition, int stopValue )
{
  float startPoint=getDistance();
  if (speed==0)
    speed=40+random(20);
  setSpeed(speed);
  if (steer==0)
    steer=100*sgn(random(10)-5);
  setSteer(steer);
  while (true)
  {
    // check for normal termination
    switch (condition)
    {
    case stopOnSonar:
      if (SensorValue[sonar]>stopValue) return brcSucces;
      break;
    case stopOnDistance:
      if (abs(getDistance()-startPoint)>stopValue) return brcSucces;
      break;
    default:
    }

    // Check for error conditions
    if (hitSomethingNew()) return brcTouch;
    if (stall()) return brcStall;
    if (speed>0 && SensorValue[sonar]<10) return brcSonar;
  }
}

/***************************************************************************************************\
*  Behaviour: goEscape                                                                              *
*  Purpose: Try to escape from a trapped situation                                                  *
\***************************************************************************************************/

TbehaviourRC goEscape()
{
  int angle, speed, distance=150,i=0;
  TbehaviourRC result;
  while(true)
  {
	  i++;
	  if (desiredAngle<0)
	    angle=100;
	  else
	    angle=-100;
	  if (desiredSpeed<0)
	    speed=40;
	  else
	    speed=-40;
	  setSteer(angle);
	  setSpeed(0);
	  distance+=10;
 	  wait1Msec(300);
	  result=driveCorner(speed, angle, stopOnDistance, distance);
	  if (result==brcSucces &&  (i % 2 ==0) && SensorValue[sonar]>60) return brcSucces;
	  if (i>20) return brcStuck;
  }
}

/***************************************************************************************************\
*  Behaviour: goRest                                                                                *
*  Purpose: Stop the car                                                                            *
\***************************************************************************************************/
TbehaviourRC goRest(TstopCondition condition, int stopValue)
{
  while(true)
  {
    // check for normal termination
    switch (condition)
    {
    case stopOnSonar:
      if (SensorValue[sonar]<stopValue) return brcSucces;
      break;
    case stopOnButton:
      if (nNxtButtonPressed==stopValue) return brcSucces;
      break;
    default:
    }
  }
}

/***************************************************************************************************\
*  Behaviour: Main, top level behaviour                                                             *
*  Purpose: Allow the car to behave                                                                 *
\***************************************************************************************************/

task main()
{
  TbehaviourRC result;
  init();

  while (true)
  {
    //nxtDisplayCenteredBigTextLine(1, "%d", state);
    //nxtDisplayCenteredBigTextLine(3, "%d", result);

    switch (state)
    {
    case STrest:
        result=goRest(stopOnButton, 3);
        if (result==brcSucces)
          state=STdrive;
        else
          state=STrest;
      break;
    case STdrive:
        result=goStraight(0, stopOnSonar, 70);
        if (result==brcSucces)
          state=STturn;
        else
          state=STescape;
      break;
    case STturn:
        result=driveCorner(0, 0, stopOnSonar, 75);
        if (result==brcSucces)
          state=STdrive;
        else
          state=STescape;
      break;
    case STescape:
        result=goEscape();
        if (result==brcSucces)
          state=STdrive;
        else
          state=STrest;
      break;

    default:
    }

}

  StopAllTasks();
}

This interesting use of Lego popped up on the mailing list of the University of Bergen. Build by a group of Norwegian Danish students, it’s a simple computer that implements Alan Turing’s design from 1937. Having both read and write functions, it implements its own (somewhat inefficient) medium of non-volatile memory. What we find interesting is that rather than move the ‘tape’ through the machine, the machine rolls over the tape. Thanks to [Thorsten] for the tip.

TFOLs (Teen/Tween Fans Of Lego) and UFOLs (Underage Fans Of Lego [9 and under]) are often disappointed by their parent’s reaction to the latest cool creation they either build or find online.  Non-Lego fans simply do not understand the rules of Lego and the effort that goes into any creation.  I cannot blame them–you cannot fully appreciate Lego unless you have built Lego yourself.  But still we want out parents to be amazed by the wonders of amazing Lego creations.  This guide highlights some types Lego creations and qualities found in Lego creations that cause a parent’s increased awe.  If you are a TFOL or UFOL and have your parent nearby, I suggest you invite them to read this post with you.  I will include an example of each item.

1. Brickfilms

Stop-motion animation with Lego is very popular.  Parents love the idea and think it is amazing that you can make a movie, of all things, with Lego.  Here is an old example built by rymdrelage to promote the song “8- Bit Trip”:

You should probably stop for a moment now to pick your mom or dad’s jaw off the floor.

Thanks to Fasinating Lego Model of The Day.

2. Robotics/Motion

You can find hordes of robotic creations online if you know where to look.  Most are made from the Mindstorms or NXT Lego robotic kits, but if that is out of your price range (NXT 2.0 costs $279.99) you can buy Power Functions Motors. 

Robots and vehicles are great, but think out-of-the-box like NeXTORM:

Amazing, right?

Thanks to The Brothers Brick.

3. Huge Size

Anything is more impressive if it’s gigantic.  Although most people don’t have enough bricks to make something the size of this model of the battleship Yamato, by Jumpei Mitsui, you can always build something impressive with what elements you do have.

Statistics:

Thanks to The Brothers Brick.

4. Creative and Original Build

Think: is a Toa really anything new?  Is a spaceship truly noteworthy?  Haven’t you built lots of custom minifigures before?  Parents may tire of seeing the same old type of creation over and over again.  But a Bionicle lobster?  They’ve never seen that before.

So there you have it- the basics on how to impress your parents with Lego.  Now go forth and build!

I just came back from Safeway. Before that, I was eating dinner. Before that, I was at the 2009 FIRST Lego League Qualifying Tournament.

At the tournament, you have to program a NXT Mindstorms robot to do certain missions that you pick. You also get scored on your teamwork, robot design, and project that has to be based on the theme. (By the way, this year’s theme was about safe ways to get to places. Basically, transportation.) On the practical part (the missions), we got 9th place out of 12. The good part? We were the first team in our region to finish a round on the red bridge. That was kinda cool.

We didn’t get any awards or anything, but all in all, it was fun. The red bridge thing was even more cool.

Learn more about the FIRST Lego League, the NXT Mindstorms kit, and everything else at:
http://www.usfirst.org/roboticsprograms/fll/ <—–FLL Site
http://mindstorms.lego.com/ <—–NXT Mindstorms Site

Ryan

I wanted free rover to have front wheel drive.
Why? I might want to use odometry, the art of knowing where you are, later on. The path of front wheels is more easy to calculate than the path of the back wheels, so I wanted encoders on my front wheels to tell me how much they have rotated. Also, I wanted to explore the various aspects of front wheel drive.

I could have used a single motor for driving and a differential to divide power to both wheels. But I choose to drive each of the wheels with its own motor.
Why?
I want more power for driving, two motors give more power than one motor. Also, differentials are weak. Also, why use mechanics if there is software.

So, I developed a drive train where aech of the front wheels is driven by a motor. There is a 5/3 gear ratio in the drive train, this will make FreeRover a bit quicker. Both driving motors are on the outside and on top of the car. I think it looks nice.

As i discussed before, both front wheels rotate at different speed while cornering. This has to be reflected in motor speed. It can be calculated how much different the speeds of the motors should be, given the turning radius of the car. Turning radius itself can be calculated from the angle the front wheels make. And this can be calculated from the number of encoder ticks the steering moter is from its center position. The math isn’t comlicated if you know how basic trigonometry.

My program doesn’t set motor speed directly. Instead it uses a function that translates the desired car speed to left and right motor speed and sends this to the motors. The steering position is constantly monitored and when the angle of the steering changes corrections in motor speed are made.

Everything seems to work fine. Without corrections the inner wheel would jitter in corners. With corrections both wheels drive smoothly.

It is time I gave credit to RobotC. It has the opportunity to set motor speed. Normally you would set motor power, you would not know how much speed this would give you. Not in robotC though. This took a lot of work from me.

However there is one thing to consider. My software solution assumes a perfect world. The steering angle must be perfectly corrleted to the radius of the turn and so on. Well, this is not always the case. A car can slip for example. A differential doesn’t suffer from this. It reacts to a real world instead of to a mathematical world. So, unless I take real world measurements in account, my solution is inferior to a differential. For now it doesn’t take the real world into account. I’m still considering some ways to do so. Also, I have not yet decided if it is worth the trouble.

My steering geometry was square. The steering wheels were always parallel to each other. However, if a car is cornering the outside wheel is making a large circle, the inside wheel is making a small circle. So, the steering angle of the outside wheel should be less than that of the inside wheel. This can be achieved with a steering geometry called Ackerman steering geometry. See the image I took from Wikipedia.

I wanted Ackermann steering. This forced me to redesign the steering mechanism and to recalculate some of the cars properties. The biggest challenge turned was to make the design sturdy. On the run I also managed to get rid of some of my previous design errors. Although I introduced some new ones.

As both front wheel have a different angle this could further complicate calculations. To overcome these complications I now base all calculations on a fictional front wheel that is placed exactly between the two real ones and that has an angle that is the average of the to real ones.

Here are two new pictures of FreeRover. One showing the steering mechanism. The other showing FreeRover in its current state. You might notice the red handle bars. These are intentionally red as the remind me to use them while handling the car. Before that I used to grab the driving motors while carrying FreeRover. Sometimes this would cause the cables to disconnect.

I had to compromise on sturdyness and cornering. It turns more slowly than it used to. Was it worth it? I don’t know.

Last week I implemented autocalibration using pid control. I found out it worked well, but only if the miscalibration wasn’t too big. It worked to about half the maximum error. After some attempts to improve tuning I concluded it must be something else.
Pid controllers only work for lineair systems and my steering function isn’t. The output, rotational speed, is not linear related the the input, being number of encoder ticks for the steering motor.

This gave me two questions. Why does it work for small errors? And can i rewrite my steering function to be lineair?

I only have some suspicion about the answers to these questions. So if you have them please post’em.

I think my steering system behaves almost lineair if the steering angle is small. This being my answer to my first question.
I also believe it is possible to write a lineair steering function. But if an error factor is added it will no longer behave lineair. As the error in rotation speed is not lineair to the error in the steering.

So I concluded that my pid function only works for small errors and that is of no use to try to improve it.

And still, i love to see my car calibrate itself all the time. Also, I’ve managed to reduce the distance needed for calibration to aboout 25 cm.

For the steering to work correctly, the steering mechanism has to be calibrated. One needs to know when the steering is centered. The easiest way is to do it by hand, remove the 12 tooth pinion, center the steering and put it back on. I used this method until today.

Today, I had a day of from work and family. I used it to make the car calibrate its steering while driving.

Calibration is done everytime the car has to drive a straight line. It then uses it’s gyro and a PID controler to drive straight. If the steering is miscalibrated this will take some time. But once FreeRover drives straight, it stores the current encoder value as steering centre. Thus calibrating the steering.

Writing a PID controller is not very difficult, but it needs to be tuned before it works well. Tuning is difficult. It took me some time to tune the PID controller but now it’s working like a blast.

The autocalibration calibrates within a meter, but well before that it corrects for an offset steering. For FreeRover autocalibration is very usefull because the steering gets lots of strain from collisions, the front wheel drive system and design errors. As a result, it gets miscalibrated very easily.

Here is the robotC code dealing with autocalibration. Note that calibration is done if the absolute value of past errors is below a certain treshhold. This treshhold is then decreased to allow for even bettter calibration. The treshhold is reset every time the car starts driving straight.

// PID controller using the gyro to tune the car for driving straight
task driveStraight()
{
  float Kp=1.6, Ki=0.008, Kd=0.2, memory=0.6;
  float error=0, integral=0, absIntegral=0, derivative, lastError=0, sumError, calibrationOffset=32;
  int i, dT=80,x=0, q=0 ;
  while (true)
  {
    wait1Msec(100);
    calibrationOffset=32;
    q=0;
	    while(state==STdrive)
	    {
	    // Read the gyro 20 times (to eliminate noise) and calculate the error;
	    sumError=0;
	    for (i=0;i<20;i++)
	    {
	      sumError+=(float)HTGYROreadRot(HTGYRO);
	      wait1Msec(4);
	    }
	    error=(-sumError/20);

	    // Test again, for gyro loop took some time
	    if (state==STdrive)
	    {
		    // If the sum of last errors is below a treshold then the car is driving straight steadily.
		    // Calibrate the center steering
		    if (q++>20 && absIntegral<calibrationOffset)
		    {
		      nMotorEncoder[steer]=0;
		      calibrationOffset=calibrationOffset/2;
		    }
		    else
		    {
		      // Calculate the values for PID
			    integral=memory*integral+(error*dT);
			    absIntegral=memory*absIntegral+(abs(error));
			    derivative=(error-lastError)/dT;
			    // calculate the steer correction value (it will be picked up by the steering task
			    steerCorrection=clip(Kp*error+Ki*integral+Kd*derivative,-80,80);
			    lastError=error;

			    // Plot the sum of the last errors.
			    /*
			    nxtEraseLine(x, 0, x, 50);
		 	    nxtSetPixel(x, absIntegral);
			    if (x++>99) x=0;
			    nxtDrawLine(x, 0, x, 47);
			    nxtDisplayTextLine(0, "E:%4.2f", error);
			    nxtDisplayTextLine(1, "I:%4.2f", absIntegral);
		      */
		    }
  	  }
    }
  }
}

Steering of FreeRover is done by means of a rack and pinion system. The rack is made out of 2 worm gears. The pinion is a 12 tooth gear that is connected to a NXT motor through a gear train. I want FreeRover to be symetrical. That is why the NXT motor is placed along the length axis of the car.

There are two things I need to know . First, what is the maximum amount of rotation the NXT motor can make (number of encoder ticks) without the pininion (wheel gear) loosing touch with the rack. And second, what is the angle of the front wheels given the amount of rotation of the steering motor.

The maximum rate of freedom of the steering rod with the 2 worm gears is about 2 studs from the center to either left or right. At its maximum the pinion (12 tooth gear) begins to loose touch with the rack (2 worm gears), beond this point the pinion does not have any contact with the rack and all control over the steering is lost. That is why I need to know how much I can make the NXT motor rotate. Let’s start with the rack. Each worm wheel has 5 teeth (the singel spiral makes 5 turns around the axis), so 5 teeth is the maximum for the rack. The pinion has 12 teeth. It’s maximum rotation is 5/12. The pinion is connected to a 20 teeth gear, it’s maximum is also 5/12. This gear is driven by a 12 tooth gear. The maximum rotation of this gear is 20/12* 5/12. From there on, I used only 24 tooth gears to the motor, these can be ignored. So the maximum rotation of the motor equals 20/12*5/12*360 = 250 encoder ticks. If the steering mechanism is pointing straight forward and I rotate the motor for 250 ticks it will be pointing full left (or right).
A nice tutorial about lego gears can be found here.

Based on this calculation I coded a function that takes an angle as input and drives the steering motor accordingly.

I also want to know what angle the wheels are making given a number of encoder ticks. The length of the steering arm is given (2 studs). The steering rod goes one stud sideways for each 125 encoder ticks of the steering wheel. This gives us the length of two sides of an imaginary triangle, the hypothenuse (2) and the opposite (encoderticks / 125). The angle of the steering wheel equals the arc sinus of encoders ticks / 250.

I made a function that returns the angle of the front wheels.

First I want to discuss steering.

FreeRover has front wheel drive. Each of the two wheels is driven by a physically independent motor. The car has rack and pinion steering, steering is driven by a third NXT motor. Rack and pinion steering means that each wheel rotates around a different axis. Also, this gives the car a fixed wheel base, therefore it is very stable. In corners, the inner wheel rotates more slowly than the outer wheel. So the motors that drive the front wheels have to turn at different speeds. How much different? That can be calculated with a little math. It does make the software rather complex. A good software design is critical. These three aspects, car design, math and software will each be discussed in later posts.

The first project on this blog will be my autonomous rover called FreeRover. It’s goal is just to drive around and avoid obstacles. I know, it has been done before and it has been done better. 

The setup of this NXT robot is different from most I have seen around. It is like a normal car, with four wheels, front wheel steering using a pinion and rack lay-out and front wheel drive.

There are some challenges for me in this project, each of them will get at least some attention here:

• Steering
• Obstacle detection
• Behaviour

Here are some pictures of the rover in it’s current state.

Sebenarnya artikel ini cocok untuk adik-adik yang berusia mulai dari 7 -12 tahun, tetapi kalau teman-teman ada yang mau belajar ya tidak masalah…kan ngejar ilmu sampai ke negeri tirai bambu…begitu kata petuah orang tua kita.

Sebenarnya saya membeli Lego Mindstorms NXT awalnya hanya untuk mencoba mengalihkan perhatian anak saya si Omy yang berusia 3 tahun dari hobby membeli dan mengoleksi berbagai tipe mainan mobil-mobilan! Selain itu agar dia interested ke mainan robot dan sekaligus meningkatkan stimul daya logikanya…begitu kata para psikolog kalau berbicara di seminar. Dan yang jelas…ini tidak ada pesan dari sponsor!

Ketika saya akan membelikan Mindstorms NXT untuk si Omy, saya sempat menelpon dan bertanya beberapa distributor di Indonesia yang aku kenal. Versi Lego Mindstorms NXT ada dua tipe, yaitu :
1. NXT 8257
Versi ini memang untuk retail dan jumlah komponennya lebih sdikit dibanding versi yang satunya.


2. NXT 9797
Versi ini sangat support untuk education version. Jadi terserah ke Anda bila mau membeli.

Ketika saya bertanya harga, distributor di Bandung membandrol harga :Rp. 4,8 jt untuk versi NXT 9797, sedangkan distributor Surabaya dengan harga Rp 5,4jt untuk versi NXT 8257. Semuanya belum termasuk ongkos kirim. Wah kok lebih mahal harganya bila dibandingkan di internet, maka kuputuskan saja beli langsung di internet. Saya beli di US dengan harga Rp. 3 jt sudah termasuk ongkos kirim untuk versi NXT 8257.

Mindstorms NXT memang didesain untuk anak-anak sehingga tidak menyulitkan mereka. Sama saat kita belajar robot, Mindstorms NXT pun sudah dilengkapi dengan beberapa bagian, antara lain :
1. Otak (mikrokontroller),
2. Sensor (ada sensor suara, jarak, dll)
3. Penggerak (servo motor)
4. Software
5. Perangkat penunjang lainnya
Belajar menjalankan Mindstorms NXT sangat mudah karena semua sudah dibuat simple, sangat berbeda saat kita belajar membuat robot dengan mikrokontroler yang harus mengerti tentang bahasa pemprograman.

Oke…introductionnya mungkin cukup sekian dulu…ntar saya sambung ke munu inti belajarnya.

Salam,

Munadi A

(Thank you again Gretchen for the summary)

Hi everyone,

We had another great meeting today!

The kids were well prepared and we accomplished a lot. We decided upon our team t-shirt and started building the legos for our missions.

Because there are many Lego parts to build we have decided to hold a meeting this coming Thursday night, Oct. 8th, from 6:30-8:00 pm. at Mitra’s house.

We have also decided to meet a little earlier next Sunday Oct. 11th. If your child can meet at 2:30 and stay until 5:30 for the Sunday meeting that would be great.   After this meeting we should have a better idea of how much more we will need to get done.

Meena has ordered the robot and we should have it this coming week.

Please email Gretchen if your child can make it to Mitra’s this coming Thursday night.

Thanks,

Gretchen 303-443-9676 home, 720-841-6015 cell

Jouer au basket ball avec le Mindstorms: sur la brique Lego, on sélectionne Gauche ou Droite par intervalle de 15 degrés. La validation se fait avec le bouton, on sélectionne ensuite la puissance de tir avec la télécommande, on valide avec le bouton et panier.

Une petite vidéo pour illustrer le fonctionnement:

Quelques photos du Mindstorms basket ball:

La télécommande au premier plan est composée d’un moteur et du bouton tactile.

Le panier de basket les points sont comptabilisés avec le capteur de lumière. Une partie compte 5 tirs, à la fin le score apparait sur l’écran de la brique.

Hello people! Welcome to the site of the First Lego League team The Jumping Jelly Beans. Here we show our success tops and flops complete with picture, video, and maybe the once in a while sound file! So just put what you think and have fun!

(Thank you Gretchen for writing this up..)

Hi everyone,

We had a good meeting today and it was nice meeting with your children. For our first meeting we discussed some of the core values, and expectations of First Lego League. We emphasized the importance of working together as a team, and exhibiting “good behavior” by respecting ourselves and others. We watched a short video of different teams at a competition.

Some core values to discuss with your child:

1. We are a team.
2. We do the work to find solutions with guidance from our coaches/mentors.
3. We honor the spirit of friendly competition.
4. What we discover is more important than what we win.
5. We share our experiences with others.
6. We display gracious professionalism in everything we do.
7. We have fun.

There are 2 separate challenge parts to Lego League; the “Project” and the “Robot Game.” (The challenge is based on a set of real-world problems facing scientists and engineers today). In the Project, our team will research a real-world problem in the field of “Transportation,” create an innovative solution, and share their findings in their community. In the Robot Game our team will design, build, program, and test robots that must perform a series of tasks or missions. They will present both the Project and the Robot Game to judges in November when we go to the competition.

Today we also discussed the design for our team t-shirt and decided upon our team name. The children chose “Jumping Jellybeans” for the team name. For Homework we have asked the children to design a logo for the t-shirt. Have them bring their design for the t-shirt to our next meeting so we can vote on this.

Also, for homework have them identify a real-world problem in their community related to transportation. They should come to our next meeting ready to share their ideas and how they might solve this problem related to transportation.

For example, one group today came up with the idea of the problem of pick up time at High Peaks Elementary. They discussed the safety issues during this time of the day and the problems of the drive through pick up circle, and also how people speed down Aurora Ave. disobeying the speed limit when the yellow lights are flashing. We also discussed the transportation issues of shipping food across the country/world to grocery stores by trucks/boats/planes and all the fossil fuels it takes to do this. (The children can go to the FLL website for ideas).

Thanks again to Mitra and her family for allowing us to use their home!

 Parents, we welcome your thoughts and ideas. Please spend time with your child going over this and have them bring their homework to our next meeting on Sunday Oct. 4th, at 3:30.

Next week we will begin to work with the Lego parts.

We will schedule an outdoor break at each meeting for the kids so they can get their energy out.

If the weather is nice we can even hold a portion of the meeting outside.

Until then,

Gretchen, Sheryl, Rich, Lee, and Mitra