• NEW Joystick Configuration Utility – Added compatibility for custom joystick configurations; the Joystick Configuration Utility can now be used to configure a wide variety of controllers for use with ROBOTC. Read about it on the Custom Joystick Controls page on the ROBOTC wiki!
• Fixed Samostat.c sample program – There was a typo in the ‘nxtDisplayTextLine(status.nLine, “%s”, status.message);’ line of the Samostat.c program in ROBOTC 3.60 that prevented it from working properly. This has been fixed in 3.61.
• Updated Robot Virtual Worlds Curriculum Companion Tables – ROBOTC now includes the latest update of the Curriculum Companion Tables which added Quality Control Settings and now provides Update Notifications as well. Find out more about recent RVW updates here.

You can download it here: [LINK].

If you’ve never used mind maps before, I can really recommend you read my article and listen to the pod-cast.  Also be sure to check out the resources on Michael’s sites.

The first on there is my Robot Virtual Worlds Maze Crawler.  If you don’t have Git, don’t worry, you can also just download the whole thing as a zip file.

Other repositories will appear on there as well at some point.  I am keen to get my Driver Suite on there soon but that is still under a lot of development and is not fit for public consumption just yet.

Some other stats:

• On the busiest day (8 Jan 2013) I had almost 3000 views.  This was mainly caused by the announcement of the EV3.
• I’ve written 412 posts in total.
• About a quarter of views come in via search engines.
• 19% of all views are people looking for the free downloadable ISOs of NXT-G 2.0.

So thank you to all my readers for spending some of your precious time on my little corner of the Internet!

http://www.youtube.com/watch?v=f73rshIDEEM

The engine for this robot consists of two Finite State Machines (FSM) that handle the cruising around, turning, scanning, etc.  Here’s a little video of it, doing its thing.

http://www.youtube.com/watch?v=ZKzCcwCQSkE

Main FSM

The main state machine consists of 5 states:

• BEGIN
  • Initialise the maze tiles
  • Set the walls of the perimeter
  • Set the pointers to the finish tile and current tile
• SCAN
  • Check for a wall ahead and fix the robot’s position if required
  • Scan left and right walls if they have not been scanned already
  • Update current tile walls and those of the neighbouring tiles
• TURN
  • Call the route planning function and get new heading
  • Change robot’s heading and wait for turn to complete
• CRUISE
  • Reset the encoders
  • Wait until the robot gets to the centre of a new tile
  • Update the position of the robot and update the current tile pointer
  • Check if the new tile is the finish tile, stop if this is true
• END
  • Stop the robot, exit the main thread

Scanning FSM

The scanning FSM has 6 states:

• BEGIN
  • Scan the wall ahead and update its status and of adjacent tile
  • Check if left and right wall are known and skip directly to the end
  • Check if left wall is know and skip directly to right wall
• TURNING LEFT
  • Change the heading of the robot and wait for turn to complete
• SCAN LEFT
  • Scan the wall on the left and update the status of this wall and of adjacent tile
  • Check if the right wall needs to be scanned, if not, go to the end
• TURNING RIGHT
  • Change the heading of the robot and wait for turn to complete
• SCAN RIGHT
  • Scan the wall on the right and update the status of this wall and of adjacent tile
• END
  • This state is only used to exit the FSM

Route planner

The current route planner is very simple, it’s a “follow the right wall” and will only work with certain mazes.  The robot uses the following algorithm to decide where to go next after it’s done scanning a tile:

• Turn using the following priority list:
  • Turn right
  • Go straight
  • Turn left
  • Turn 180 degrees

That’s it.  Nothing more to it.

Modifying the route planner

If you wanted to experiment with different route planners, simply change the function called in doMainStateTurn(), which gets called each time we get to another tile.

/** 
* MAIN_STATE_TURN 
* 
* Here we see which way we'll go next.  The actual decision is made 
* by a route planning function, routePlannerFollowWall() in this case 
*/ 
void doMainStateTurn() 
{ 
  writeDebugStreamLine("doMainStateTurn");

  int dir = headingToDirection(currentHeading); 
  int newHeading = requiredHeading;

  // Get a new heading from the route planning function 
  newHeading = routePlannerFollowWall(dir, maze, currentTile);

  // Don't bother to do anything if the newHeading is the same 
  // as the current one. 
  if (newHeading == requiredHeading) 
  { 
    setMainState(MAIN_STATE_CRUISE); 
    return; 
  }

  writeDebugStreamLine("doMainStateTurn: dir: %d, curr: %d, new: %d", dir, currentHeading, newHeading); 
  updateMotors(TURN_SPEED, newHeading);

  // wait for the turning to be completed. 
  while (abs(currentRelativeHeading) > 5) 
    wait1Msec(10);

  wait1Msec(1000);

  // Go to the next state 
  setMainState(MAIN_STATE_CRUISE); 
}

Future improvements

Things that would be cool to add:

• A route planner that makes sure that all tiles are discovered and mapped.
• A route planner that will work with mazes that are not perfect
• A solver that will find its way back to the start using the fastest route

Download the code

You can get the code and the RVW level here in a single zip file.  Make sure you select the “Mammalbot” as your robot or it won’t work.

This site will continue to be the source for my tutorials and larger articles, product reviews, etc.  I will also use Tumblr to post links to these articles, so you won’t miss anything.

I was approached last week by TechWeek to take part in a competition to design an office device. My device is a fairly simple one, maybe not to make, but certainly to use.

What is it?

It’s the iPIckU, a RaspberryPi based device to help you pick a volunteer for the job that nobody wants.  The device consists of a button, a finger print scanner, a small mic and a speaker.

How does it work?

To operate it, the first person presses the button and scans his or her finger and passes it along to the next person. The last person presses the button again to finish scanning all the participants. Each time a person scans, the iPIckU will check if he or she is known.  If this is not the case, the user will be prompted to say their name, which will be sampled and stored on the device. If the person is known, a previously recorded sample of them saying their name will be played.  The iPIckU will play that person’s sample with their name. After the final button push, the iPIckU’s Random Volunteering System™ will pick a victim and play the sample of them stating their name.

How will it be implemented?

The tough part will be the finger print scanner. A time-saver would be a unit that can do most of the hard work for me by identifying the print, or at least returning some kind of cryptographic hash that can be matched against an identity database.  A regular USB mic will be used to record the sound using one of a myriad of recording utilities for Linux.  Replaying the sound can be done through the RasPi’s audio-out and a small speaker. The button will be handled by a simple GPIO pin, as will the various status LEDs. A pot meter can be used to control the volume of the speaker.

…I concluded that I feel better about sharing them with as many people as possible than sharing them with a handful and making a few bucks.

Despite all the effort that went into making them, he’s decided that it’s better to share than to sell.  That’s how communities are built, so kudos to you, Pepijn!

There are some pretty cool models on the site, which you can find here: [LINK].  I especially love the skating robot, which you can see in a video below:

http://www.youtube.com/watch?v=rbyzNncWOCg

The Solar Powered robot is also great, it’s based on the Twenthe One, a solar powered vehicle, which was made for the World Solar Challenge.

http://www.youtube.com/watch?v=z7Q4_FdcGCM

There are quite a few other ones there as well, but I think I will have a go at making the skating robot first.

• An even easier to use Natural Language, to make getting started with ROBOTC more intuitive
• Leveraging the EV3’s and VEX IQ’s ability to auto-id connected motors and sensors, you’ll be able to configure ROBOTC’s motor and sensor configuration automatically.
• Make drag and drop even better to make it easier to use for new users.
• A much fancier editor that does stuff like code collapsing (yum!), better auto-complete and improved tweakability.
• More programming examples, for both the existing and new platforms.
• The VEX version will support VEX Cortex and VEX IQ
• The MINDSTORMS version will support NXT and EV3
• Just like what they did with for the RCX when going to ROBOTC 3.x, a free stand-alone version will be made for VEX PIC users.

If you’re concerned about buying ROBOTC now, don’t worry, you will be able to upgrade as soon as ROBOTC 4.0 is released.  Not all pricing details have been finalised but they’ve made a list of people who are eligible for upgrades and at what price.

Current ROBOTC Users Upgrade Details:

• 3.0 Perpetual Users (who purchased in 2013): No upgrade fee! Full purchase price will be applied towards same type of license for 4.0.
• 3.0 Annual Users (who purchased in 2013): 50% discount on equivalent 4.0 License
• 3.0 Perpetual Users (who purchase before 2013): 50% discount on equivalent 4.0 License

Upgrades will be available for up to 6 months after the official release of ROBOTC 4.0.  Beta version of 4.x will be made available for playing with throughout the summer, so make sure you keep checking back here or at the official ROBOTC blog.