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
Sent: Tuesday, October 23, 2012 8:13 PM
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!
Sincerely,
Bob Henshaw
To UNSUBSCRIBE
or CHANGE your settings, please visit https://listserv.jmu.edu/archives/vadcfll-l.html
and select "Join or leave the list".
VADCFLL administrative announcements
are sent via VADCFLL-ANNOUNCEMENTS-L. Visit https://listserv.jmu.edu/archives/vadcfll-announcements-l.html
to subscribe.
To UNSUBSCRIBE or CHANGE your settings, please visit
https://listserv.jmu.edu/archives/vadcfll-l.html
and select "Join or leave the list".
VADCFLL administrative announcements
are sent via VADCFLL-ANNOUNCEMENTS-L. Visit
https://listserv.jmu.edu/archives/vadcfll-announcements-l.html
to subscribe.