VADCFLL-L Archives

First Lego League in Virginia and DC

VADCFLL-L@LISTSERV.JMU.EDU

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael Brown <[log in to unmask]>
Reply To:
Michael Brown <[log in to unmask]>
Date:
Mon, 7 Oct 2013 14:03:14 -0400
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (6 kB) , text/html (9 kB)
Could not agree more, the motor reset block is extremely valuable in
getting your robot to behave correctly.

When squaring up on a wall using a seconds in a move block, instead of
degrees or rotations, use a motor reset lock to prevent errors from motor
memory.
On Oct 7, 2013 1:54 PM, "John Barrett" <[log in to unmask]> wrote:

> Brandy,
> Good advice all around.  I would always tell my teams "Every second you
> spend in base is a second your robot is not scoring points"
>
> Practicing and perfecting mission starts from base results is much better
> scoring.  And I agree that inconsistent robot performance is often a result
> of operator error and not the robot itself.
>
> I will add, though, if your team is working with a single, master program,
> then the motor memory could cause one mission to affect the next mission.
>  In situations like this (one single master program), a motor reset at the
> start of each mission can help.
>
> John
>
> ------------------------------------
>
> John J. Barrett
> Industrial Medium Software, Inc. | 1616 Anderson Road | McLean, VA 22102 |
> http://www.industrialmedium.com
> (cell) 703-231-5094 | (office) 703-286-0818 | (fax) 703-286-0888
>
>
>
> On Oct 7, 2013, at 12:36 PM, B Bergenstock wrote:
>
> My old FLL team figured out it was never programming the missions or
> coming up with amazing attachments that killed their score, it was *the
> switching*.  It was having 1 attachment do one mission, and then take it
> off and put on the next attachment that resulted in lower robot game
> scores.  Their best score in their 3 years was the year they figured out to
> adapt 2 attachments to participate in 8 missions :)
>
> That and always trying to start from one place in base (as much as
> possible anyway). I know it's probably too late to help a lot of teams with
> that tip, but the more missions you have that start in one place, the
> better the chance that the operator will get it right and the robot will
> hit it's target, as just a few degrees off in a mid-field mission can be
> disastrous at the wrong angle. Sensors can greatly aid in correcting for
> small errors, but hooking or slicing the robot when placing it down may be
> difficult to compensate for since it can miss its sensor's mark.  Practice
> here does make perfect!  It's nice when teams keep track of whether a
> mission worked well or not.  Understanding the percentages of achievement
> right before a tournament can take the guesswork out of what missions to
> run on the table in a time crunch.
>
> If you can't start in one place, at least have the team do themselves a
> favor and don't float the robot in the base. Have it start off a wall, or
> make a lego ruler to create the angle you need and be consistent with the
> starts each time.  The increase in accuracy from starting off a wall is
> significantly higher than floating "the back wheel off the side of the M",
> or "having to count 7 dashes in the left side base to line up the back
> wheel". Just don't.  I noticed with my team that one operator would
> complain about a mission* never *working, but put a different operator
> down there to start it off and it was a 95% accurate program. Our first
> year was fraught with us blaming the robot for what turned out to operator
> error that would have been solved by following this simple best practice
> "start rule".
>
>   If you are seriously considering that two chassis concept, have the kids
> do several runs (like 5-8) with and without chassis changes and see what
> their final score would be in a timed match.   I recommend not adding any
> new programs the week before competition; Perfect programming, but no new
> ones. Practicing our robot game starts and just getting lost of face time
> with the game we were going to run at competition, we learned it made for a
> much higher score!
> Regards,
> Brandy
> FTC 6193
>
>
>
> On Mon, Oct 7, 2013 at 9:40 AM, Bdh612-ess <[log in to unmask]> wrote:
>
>> My team considered that, but besides the complexity issue, we worried
>> about the transition time and robot bloat issues in trying to provide the
>> switch-ability mechanism.
>>
>> That said, I'd live to see the video, could you post a link?
>>
>> Brian
>>
>> Sent from my iPhone
>>
>> On Oct 7, 2013, at 9:07 AM, Alex <[log in to unmask]> wrote:
>>
>> Answer for question two.
>>
>> There is a team that does the multiple chassis plan. The motors and
>> programmable brick are moved.
>>
>> There are youtube videos that show them switching between missions.
>>
>>
>> On 2013-10-07 07:46, Larry Landsberg wrote:
>>
>> 2 separate questions. Hoping for 2 separate answers.
>>
>> 1. Can you use multiple robots during the tournament, ie 1 robot (EVS) for the first mission we attempt then a second robot (NXT ) for the next mission we attempt?
>>
>> 2. Can we have two different chassis but 1 brick that we switch between chassis during the tournament?
>>
>> Thank you,
>>
>> Larry
>>
>> -- 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.
>>
>> ------------------------------
>> 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.
>
>
> ------------------------------
> 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.


ATOM RSS1 RSS2