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.