That's a good challenge. There are probably lots of ways to
handle it, but here's one method that might work well and be generally
First, each working routine can become a MyBlock. That way they
are easy to handle, look like what was originally built, and
Then, they can be combined into a single program that calls each
MyBlock in turn. Inside the MyBlocks, the beginning and/or end will
need to be changed, as the robot won't be starting/ending in BASE in
That's enough to get the whole thing working as a single program.
However, it does leave the problem of having a 2.5 minute (hopefully!)
routine, so it's difficult to work on the last parts. It will be handy
to be able to run each MyBlock individually, to work on just that part
of the routine. What's needed, then, is to be able to place the robot
where it will be between each pair of MyBlocks--i.e., at the
To do this, I would insert a pause (and maybe a beep) in the main
program, between each pair of MyBlocks. When the robot stops and
beeps, the team can note and mark the exact location of the robot on
the competition table. Later, if they want to run just the second or
third MyBlock, they can place the robot at those intermediate
Later, the pauses and beeps can be removed.
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
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
I'll post my suggestion tomorrow.
To UNSUBSCRIBE or CHANGE your settings,
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