For your first problem I have one small suggestion in addition to those from others.  You say you deleted the program and recompiled, but that sounds like you deleted it from the brick and recompiled the same program.  Sometimes the source program is corrupted under the covers and the solution is to make a new program from scratch with all the same logic, blocks and settings.  This has helped folks occasionally in the past.

For your second problem, the usual culprit is temporary loss of traction.

Consider this real life example - If you stomp on the gas pedal of a dragster, both wheels spin (lose traction) until they regain their grip at which point they propel the car forward.  If one of the wheels grips first (as it will), the car will turn slightly before the next wheel grips.  The driver, of course, corrects for this immediately and instinctively.

This is often seen on the robot when you try to drive in a straight line from a stop using a Move block - but you start with too high a power level.  One or both wheels slip on the mat (almost imperceptibly) and the robot turns (ever so) slightly and THEN goes pretty much straight forward.  Over any reasonable distance, the variation is significant but random.  The solution is to lower the initial power setting or put more weight on the wheels to keep them from slipping.

The same principle applies on one or two-wheeled turns.  The rotation sensors are fairly precise, but they don’t know that the wheel slipped.

One of my teams had found that their robot turned really well except with one huge attachment which made its turns less predictable.  They thought it was the weight of the attachment, etc.  As it turns out, the way it attached to the robot caused the front of the robot to rise up – just a teensy bit – and that was enough to take some weight off the 2 front drive wheels and allow them to slip more.  Decoupling it from the robot greatly improved it.

Another team had a robot with two drive wheels and a skid in the rear.  They added motors and attachments that balanced the weight more on the skid than on the wheels.  This contributed to very irregular steering until it was discovered.  Moving the center of gravity over the drive wheels made the difference.

This is a great opportunity to teach them about friction, torque, center of gravity, etc. Choice of wheel type makes a difference too.  A flat wide wheel has more surface on the mat than a narrow, rounded one.  Remember to ask leading questions to get your team to discover these concepts on their own!

If they have an irregularly-performing mission have them insert a Wait block to stop the program after the first movement.  Run it ten times and see if it basically ends up in the same place.  If not, figure out why.  Then move the Wait block to after the second movement.  Run the program ten times... (rinse and repeat).  It is great to be able to teach them an engineering process along the way!  If any movement or mission works 9 out of 10 times that’s excellent for a snap-together plastic robot on a slick mat.  Testing only once doesn’t help because there’s no way of knowing whether THAT test was an outlier or not.

Forgive me if I went on and on about stuff you already know!

Stuart Roll

From: ak25455 
Sent: Tuesday, October 23, 2012 8:13 PM
To: [log in to unmask] 
Subject: Re: [VADCFLL-L] looking for help with erratic robot behavior

I would reload the firmware.

Sent via the Samsung Galaxy S™III, an AT&T 4G LTE smartphone

Glenn Roberts <[log in to unmask]> wrote:

My gut says there’s a subtle bug in your software.  Not sure, is there any way to share an NXT program with this email group so others can look at it?


From: First Lego League in Virginia and DC [mailto:[log in to unmask]] On Behalf Of Bob and Ann Henshaw
Sent: Tuesday, October 23, 2012 7:16 PM
To: [log in to unmask]
Subject: [VADCFLL-L] looking for help with erratic robot behavior


I am a 5 year veteran home based coach with a 2nd year team of 10 year olds. We are working with a Mindstorms NXT system that we purchased new last year, with a fully recharged battery. We are experiencing several intermittent erratic behaviors (listed below) that is driving our team crazy. Please let us know if you have any debugging suggestions.


Observed behaviors:


<!--[if !supportLists]-->1.       <!--[endif]-->After completing a planned series of instructions, with the last instruction having 2 wheels turning equally (straight line), the robot suddenly makes an additional turn (one motor, rotating robot about 30 - 40degrees). This occurs even after deleting the program, recompiling and redownloading it, and even after adding an all motor stop block to the program. Our team is referring to this as a ghost and are convinced that the robot is now haunted, just to get us in the Halloween mood. 

<!--[if !supportLists]-->2.       <!--[endif]-->The robot, using a two wheeled turn (one motor going forward, one going backward) intermittently turns too far or too short. Programming is being done in rotations for both motors. Because both motors are running together, I can’t tell if it is related to the problem above. This occurs about 1 in 5 runs.


I do not think that this is a cable issue, as we are not seeing anything beyond the usual minor navigation errors due to lineup, wrinkles in the mat, etc. That leaves the motors and the NXT itself. Could this be a bad servo motor and if so, is there any way to test them? 


Appreciate your suggestions!


Bob Henshaw


To UNSUBSCRIBE or CHANGE your settings, please visit and select "Join or leave the list". 
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit to subscribe.

To UNSUBSCRIBE or CHANGE your settings, please visit and select "Join or leave the list". 
VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit to subscribe.

-- To UNSUBSCRIBE or CHANGE your settings, please visit and select "Join or leave the list".

-- VADCFLL administrative announcements are sent via VADCFLL-ANNOUNCEMENTS-L. Visit to subscribe.