Thanks!

I had not come across this block before. Looks like it is hidden in the
advanced tab. From what I can tell from online programming guides, the motor
reset block not only resets the rotation sensor (which we were attempting to
do with the rotation sensor block) but also zeroes out the automatic error
correction counter. Obviously the rotation sensor reset alone was not
helping us.

 

For other interested teams/coaches, I found this suggestion on the web:

 

08-18-2010, 03:07 PM #2  

Dean Hystad 

Dean Hystad is offline Senior Member 

Join Date:Sep 2008Location:MinnesotaPosts:2,247

 

Default Re: Difference b/w Reset Motor and Rotation Sensor blocks? 

 

The short the only thing the two blocks have in common is that they do
something with the rotation sensor.

Reset on the rotation sensor block resets the reported rotation sensor value
to zero. It has no effect on the PID for the motor, and I would assume
doesn't affect a MOVE or MOTOR command in progress.

The Reset block clears out the error accumulator that NXT uses to "fix"
errors in consecutive moves. This does not affect the value reported by the
rotation sensor.

Use Reset in the Sensor block when you want to reset the reported degrees
value. If I want to start something and wait until the rotation sensor moves
50 degrees I would probably use this block to reset the degrees to zero
first.

Use the Reset block if you want the next move to behave like it was the
first move. My girls use this in their big mission manager so that each
mission starts with a clean slate, just like if each mission were its own
program.

Is that clear? The documentation is pretty clear on this.

 

 

I will definitely have the team try it at our next session.

Bob

 

From: Michael Brown [mailto:[log in to unmask]] 
Sent: Sunday, December 01, 2013 2:52 AM
To: Bob and Ann Henshaw
Cc: [log in to unmask]
Subject: Re: [VADCFLL-L] myblock programming problem, looking for advice

 

Between each myblock try using a motor reset block to zero out the motor.
You should do this for every motor. 

some teams have great success using this strategy, but I've never seen my
teams able to really use this strategy successfully. A mission doesn't
complete correctly and then you're off in the program and it doesn't work. 

Best lot of luck to you and your team.

Michael Brown
ESVA FLL Mentor
"What we discover is more important than what we win."

On Nov 30, 2013 11:43 PM, "Bob and Ann Henshaw" <[log in to unmask]> wrote:

Dear FLL community:

 

We are looking for advice regarding an unexpected programming problem with
our robot. Sorry for the long explanation, but I wanted to clearly state
what we are observing.

 

We are trying to combine 4 separate missions into a single mission with 4
sections triggered by a touch sensor. To do this, each separate mission has
been saved as a myblock (eg MB1, MB2, MB3, MB4), which run in sequence
between wait loops triggered by the touch sensor (eg. MB1, wait, MB2, wait,
MB3, wait, MB4). 

 

The first problem we encountered was that the A motor (which controls our
attachments) was locked and not moveable as we tried to exchanged our
attachments and reset the position of the motor between segments. We
addressed this by using a motor stop at the end of each myblock to unlock
the A motor. (eg. MB1, stop, wait, MB2, stop, wait, etc). This allowed the
motor to be freely moveable and allowed us to reposition each attachment at
the right angle. 

 

However, when running this program, we found that the A motor, starting in
our second segment (MB2), moves much further than programmed. For instance,
the A motor would move over 200 degrees instead of 120 degrees, causing the
robot to get stuck. 

 

Our initial thought was that we were running afoul of the rotation sensor of
the A motor as we manually moved the motor with each exchange of
attachments. To address this, we attempted to reset the rotation sensor
using the rotation sensor block, with the A motor checked, Action set to
Reset, and the compare degrees set to 0. We tried placing this reset block
both before and after our wait loops, with no change in the observed
behavior. (eg. MB1, stop, reset, wait, MB2 etc   no different than MB1,
stop, wait, reset, MB2, stop, wait etc). 

 

We also tried unplugging the A motor between missions, trying to see if this
would manually reset the A motor, without any change in this behavior.

 

Our 4 missions continue to work well as individual programs and we will
likely continue to operate with 4 separate programs. However, we have spent
a fair amount of time as a team trying to determine why the robot is
exhibiting this behavior. 

 

Thanks for any and all suggestions.

 

Sincerely

Bob Henshaw

 

 

____________________________________________________________________________
___

Ann and Bob Henshaw

3808 Fort Worth Ave

Alexandria, VA 22304

 

  _____  

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.