Previous Meeting: ParcMeeting20100321
Next Meeting: ParcMeeting20100418
Schedule
April 4th, 2010 -- 3PM to 5PM
Prerequisites
Please make sure to bring a functional "Good Base Mobile Robot" to the meeting. Either the same one from the previous meeting, or a suitable replacement.
Agenda
The primary agenda will be based on finishing up Session-1 at ParcCourse compared to where the three teams progressed to on ParcMeeting20100321.
The tentative agenda is:
- Explaining about programming with NXT-G and Robotics:
- CRC-ish basic NXT-G programming concepts (basics, loops, sensor events)
- Suggest people review when they get a chance:
- Maybe for anyone interested:
- Nxt-G issues associated with multi-tasking and Event reaction. A barrier to a well-behaved robot
- Demo Llama
- What other languages look like (intro)
- FLL and Robotics -- Maybe another video if people want
- Doing a fun/simple FLL-like task
- Robot Activity #1
- [Check] Break into pairs or triplets
- [Check] Build a Good Base Mobile Robot (Shooterbot [Nxt2.0], Tribot, CastorBot, Tank-bot [nxt2.0], etc.)
- Mission #1 -- Make it cross a table (say 4-feet or 6-feet) and return to its starting position
- Mission #2 -- Cross the table, turn-around, and return to base
- Mission #3a -- "Patrol" the table. Go back and forth until a sensor [your choice] detects something. Stop patrolling and raise alarm.
- Mission #3b -- "Patrol" the table -- go around in a square. If detect, raise alarm for 10 seconds. Continue patrolling (from where left off).
- Mission #3c -- Add some kind of shooter. Raise alarm and shoot
- Team Activity #1
- Done Altogether
- Describe Why You Like Robots (1 minute or less)
- Describe one of your favorite robots or robot-like entity
- Look through the 2009 FLL names (or any others you know) and pick one or more names you like
- Describe a favorite colour
- Describe another kind of mascot you think is neat (e.g. Unipegs)
- Propose 1 or more team names or team-name ideas
- Someone write it all down on the Wiki at ParcTeamNames
- Describing the club and what it is about
- Purpose: Learn about Robots, Build Cool & Useful Robots, Have Fun, Produce an FLL team
- Values: FLL "Gracious Professionalism" / Other
- Gracious Professionalism encourages high-quality work, emphasizes the value of others, and respects individuals and the community. Fierce competition and mutual gain are not separate notions. Children learn and compete like crazy, but must treat one another with respect and kindness in the process.
- Adults / Coaches: Inspirations and Supporters, not Doers
- [MLF: Seems like people are asking to postpone this]
- Overview of Available Resources (Wiki, Email, Blog, Robots, Table, Camera, etc.)
- [MLF: Seems like people are asking to postpone this]
-
Other agenda topics are likely to be:
- Next meeting -- Where, Food, Leader
Resources
- [Check] Meeting Location -- Doreen's house [location by email]
- Kids -- How many to attend [Maya, Zach, ...]
- Computers -- How many that are NXT-G setup [Mark = 2, ...]
- NXTs -- How many [Mark = 2]
- [Check] Floor space for multiple running robots (see Robot Activity #1)
- [Check] Projector
- [Check] Food, Drinks, Utensils
Subgroup & Post Meeting Special Topics
A Well Behaved Robot
One of the more important, advanced, and (unfortunately) complicated aspects to work with in NXT-G is being able to "Move a distance or until a sensor event". The problems are:
* NXT-G has no 'event' processing / interrupt capability within its loops (RCX actually had that)
* The smarter blocks like 'Move' are blocking when they do things like go-until-sensor
* A couple of the sensor blocks are a little more obscure than you would expect, requiring a 'reset' before use
An approach to solving this problem that was showed today was:
* Turn a move/motor on -- forever, so the block finishes immediately
* Enter into a loop that
* Reads one sensor (Sensor A), and immediately continues [a yellow block]
* Reads a second sensor (Sensor B), and immediately continues [another yellow block]
* Combines the Logic output (the "Yay") of the two readings together, and immediately continues [dark orange block]
* Loops unless the Logic Block (an "Or" of either sensor) is true [loop until logic]
* Then stops the motor
The core example is below. This one uses a timer, which is what Team-2 used:
The Logic block is set as follows to produce the 'Or' output:
The motor is started and immediately goes into the loop block. The loop block will run until either the yellow Timer is triggered or the yellow Ultrasonic is triggered. Both of these blocks immediately continue to the next step and do not block. If either is triggered by the end of the loop, the loop stops and goes to the next green block, which stops forward progress. Note-1: This loop is a "tight loop" and executes over-and-over rapidly. None of the blocks in the loop wait for anything. Note-2: The outputs of the yellow blocks are the logic check output (the [Check]/[X]), and not the timer or ultrasound value. You have to open the Data Hub to get access to these outputs. Expanded the center block looks like this:
For both the Timer and the Rotation sensor, you need to reset them before the loop. So the full 'algorithm' / idiom is:
Where the added block after the first move is a reset [notice its little icons], and not a reading.
After this loop finishes, you need to figure out why it stopped. The simplest approach is to just check one of the sensors again. The following checks the ultrasound value via an 'if'.
And then putting all this into a nice big patrolling-kind-of-loop, you get:
The idiom is not trivial, but I am hoping it is fairly intelligible after (1) Getting a feeling of real-time systems, blocking, and event issues (2) Just seeing and trying it. Comparing this to how a different language might achieve the same results [and efficiency issues of both], would be interesting.
NXC
There are alternative languages for the NXT. One simple one is NXC, so I demoed a simple version of that. An example of NXC is below:
$ more test1.nxc
task main() {
TextOut(0, LCD_LINE1, "Hello World");
Wait(SEC_10);
}
And decompiled NBC / Assembly Language for the same looks like the below. It is much more complicated and less useful unless you really want to study machine / assembly language:
$ more test1.nbc
; test1.rxe
; -------------- variable declarations --------------
dseg segment
;------- definitions -------
c000C_def struct
sw000D sword
sw000E sword
c000C_def ends
c000A_def struct
sb000B sbyte
c000C c000C_def
a000F byte[]
ul0011 dword
c000A_def ends
;------- declarations -------
ul0000 dword
sl0001 sdword
sl0002 sdword
sl0003 sdword
ul0004 dword
uw0005 word
sb0006 sbyte
ub0007 byte
ub0008 byte
sb0009 sbyte 16
c000A c000A_def
a0012 sdword[]
a0014 byte[]
a0016 byte[] 'Hello World'
dseg ends
; -------------- program code --------------
thread t000
arrinit a0012, sb0006, sb0009
set sl0001, 0x0
mov sl0003, sl0001
set sl0001, 0x38
mov sl0002, sl0001
strcat a0014, a0016
mov c000A.c000C.sw000D, sl0003
mov c000A.c000C.sw000E, sl0002
set c000A.ul0011, 0x0
mov c000A.a000F, a0014
syscall DrawText, c000A
mov sl0001, c000A.sb000B
set sl0001, 0x2710
mov uw0005, sl0001
subcall t001, ub0007
exit -1, -1
endt
;-----------------------------------
thread t001
gettick ul0000
add ul0004, ul0000, uw0005
lbl0030: gettick ul0000
brcmp LT, lbl0030, ul0000, ul0004
subret ub0007
endt
Comments (0)
You don't have permission to comment on this page.