VADCFLL-L Archives

First Lego League in Virginia and DC

VADCFLL-L@LISTSERV.JMU.EDU

Options: Use Forum View

Use Proportional 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:
Reply To:
Date:
Wed, 14 Oct 2009 11:02:45 -0700
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (4 kB) , text/html (6 kB)
Mike:

Great recommendations!

I like so much to what you said - "Add a pause and a beep between each one, so that the team can
mark the exact resting spot of the robot at those transitions."

Excellent choice of the words - "RESTING SPOT" of the "TRANSITIONS" - reminder me of the rest areas at the highways - the travelers got refreshed and the vehicles got refueled.

Or got RESET.

The key is to reset the position and orientation of the robot consistently at a resting spot for a transition (hand-over point from subset program made by one subgroup to another).

In a general sense, don't you think "resetting the position and orientation of the robot at a few places along the way of mission execution" is an very effective way to get  consistent mission execution result?

A great showcase provided by 2007 Team Brothers Keepers on Youtube -
 
http://www.youtube.com/watch?v=UuLPhTqQte0

Obviously, If not "bumping", "hugging" or "rubbing" the walls of the table, the team won't be able to execute all missions with ONE RUN.

"Bumping", "hugging" or "rubbing"
 the walls are part of ORIENTATION RESETTING methods.

Bumping and hugging the walls are methods of POSITION RESETTING too! Another well known way is to read the BLACK STRIPS on the mat that come across your planned robot route - the "lines" perpendicular to the route provide very precise position reference, the angled  / curved ones are not bad either if being used properly.

Now anything else besides walls and lines can be objects that effectively provide RESETTING?

Looking into 2009 field, ask your team members what mission models may be used as  ORIENTATION or/and POSITION RESETTING objects. An obstacle in sight may provide an opportunity for RESETTING. 

Don't give up any ideas without trying out them seriously.

Jin


--- On Tue, 10/13/09, Michael Blanpied <[log in to unmask]> wrote:

From: Michael Blanpied <[log in to unmask]>
Subject: Re: [VADCFLL-L] How to effectively sectionize a big NXT mission run program?
To: "Jin Ye" <[log in to unmask]>
Date:
 Tuesday, October 13, 2009, 5:03 PM


Re: [VADCFLL-L] How to effectively sectionize a big
NXT mi...


I would put each sequence into a MyBlock.


Add a pause and a beep between each one, so that the team can
mark the exact resting spot of the robot at those transitions.


Then the robot can be manually placed at any transition, and just
the next MyBlock tested.


Mike






Scenario -



The 09 Challenge tasks in NE area of the field have been sectioned to
3 sub-groups and three subgroups of your team have been assigned to
each of them and they have made good progress on programming and
testing each NXT program that they made. Each one is executed starting
from BASE and returing the BASE at the end. However, as they expected,
total accumulative time for all three is like 2 min.



They wonder if they can combine and refine the all three programs,
they then can take care of the multiple mission tasks in NE area BY
ONE RUN, the great amount time will be saved.



So your team is writing and testing an NXT program to deal with all
tasks in NE area of the field  and the program is called
'ne.rbt'



The BIG problems that I can see are -

1 - now so many NXT blocks are in the program. Since they are executed
in a serial sequnece (one action follows another), more accumulative
errors are likely surfaced - a little off at the early steps may cause
late steps waaaay off.

2 - Even if you program intelligently (using sensors) so the
accumulative errors are small, you still have to run ALL early steps
to get to the late steps in order to test them.



So your team want to find a way for each of the team subgroup to work
on a subset of the entire program ('ne.rbt'), and when each of subsets
is fine-tuned, the team can quickly combine them to get entire
'ne.rbt' without much re-program and re-testing!



Experienced coaches and mentors - any suggestion to VADCLL
community?



I'll post my suggestion tomorrow.



Jin






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-ADMIN-L.
Visit https://listserv.jmu.edu/archives/vadcfll-admin-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-ADMIN-L. Visit https://listserv.jmu.edu/archives/vadcfll-admin-l.html to subscribe.







ATOM RSS1 RSS2