Jin,
Are we still set for Cherry run Lego League tomorrow? Please bring your
robot and some of the attachments you had with you at the meetings at the
library. Our boys just need to see what is possible they are really stuck
with building ideas.
We are meeting in the cafeteria. When you are facing the front of the
building its to the far left there are doors to get into the cafeteria.
Thanks, see you then
Liz Reid my cell 703 774 6556
On 10/14/09 2:02 PM, "Jin Ye" <[log in to unmask]> wrote:
> 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
> <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.
|
