Chronology Current Month Current Thread Current Date
[Year List] [Month List (current year)] [Date Index] [Thread Index] [Thread Prev] [Thread Next] [Date Prev] [Date Next]

Re: [Phys-l] Robotics course help?



On 01/12/2008 11:12 AM, ovk wrote:
OK, I start a new 14 week robotics elective for high school seniors
on Monday (never taught before).

If it weren't for things getting done at the last moment,
nothing would get done at all.

... have planned out
the whole 14 weeks - but really won't know how good/realistic the
plans are =)

It is hard to comment on the plans without seeing the plans.
Maybe it would help to post the plans.

It is also hard to comment without knowing the background of
the students.

You're going to spend more than half the time teaching
programming techniques. What kinds of computer programming
expertise do the kids have?

Similar questions apply to the teacher: What kinds of
computer programming expertise?

The /kinds/ of experience is important. I would rather teach
this stuff to 13-year-old kids with *no* experience than
teach it to adults with years of experience using "standard"
programming languages (basic, fortran, C) because the kids
have fewer bad habits and are more open to new ideas.

I managed to get my hands on some LEGO NXT sets,

Good move.

You are going to want some computers that speak bluetooth.
My laptop does, most Macs (if they have any wireless at
all) do, but lots of other desktops don't, and lots of
older laptops don't. One solution is
http://shop.lego.com/ByCategory/Product.aspx?p=9847&cn=389
Similar things are available at BestBuy for about the
same price.

If the NXT kits are what I think they are, you will quickly
discover that they don't have enough sensors and actuators.
Kids will soon want to build robots that require more
sensors, for "feelers", for limit switches, et cetera.
Given how expensive the core NXT module is, it seems crazy
to be penny-wise with the sensors. Once upon a time I
built a whole bunch of sensors from scratch, using paper
clips and such. The build technique was too tricky for
high school students to do on their own, so unless you
really enjoy building stuff, you're probably better off
just buying sensors from Lego.

To avoid running out of sensor ports on the NXT, it is
worthwhile (and easy) to hack the mechanical switches
as follows: Put a 1/2k resistor in series with one
switch, a 1k resistor in series with another, and a 2k
resistor in series with another. Then hook all three
switches to the same sensor port, in parallel, then read
out the port as a /proportional/ sensor rather than as
a switch, and figure out in software which combination
of switches was actually closed.

More generally, there is a huuuge amount of information
on the web. For starters, try
http://www.google.com/search?q=lego+nxt+hack

Also (!) ... This provides a good opportunity to teach
kids about open source.

how good/realistic the plans are

Realistic? That depends on what you mean by "real" and what
you mean by "robotics". The word means different things to
different people.
-- At one level, it might mean "given a roomba, how do
I get it to vacuum half this room and not the other half"
-- At another level, it might mean "how do I design a
Mars rover robot from scratch, including the vision
system, the route planning system, and the articulation
of the arm". There's lots of graduate-level research
that goes by the name of "robotics".
-- And lots of stuff in between.

A high-school-level introductory course is a step in the
right direction, but nobody should think it covers even
one percent of "real" industrial-strength robotics.

=======================

Do you have a plan to control shoplifting?


On 01/12/2008 12:21 PM, Brian Blais wrote in part:


.... I did *not* use the
graphical language that comes with the NXT. This language is
probably ok for middle-school, possibly high school, but I prefer a
"real" language if it is to be transferrable.

I disagree as to what constitutes a "real" language.

IMHO students are much better off if their first experience
of computers is an asynchronous event-driven language such
as is provided by Lego, GameMaker, or Labview (in contrast
to old-fashioned imperative languages such as BASIC, FORTRAN,
or C). Similarly the drag-and-drop paradigm is preferable
for beginners (in contrast to the type-in-some-text paradigm).

I'm not saying that writing code is bad. Rather I'm saying
that when kids get stuck, and I tell them that the problem
cannot be solved within the limitations of the drag-and-drop
language, but can be solved by writing code, it gives them
the perfect motivation to learn to write code. This is
incomparably better than starting on day one, trying to
motivate them to write code before they understand what
it's good for. It's a question of where is the X-intercept
on the graph of gratification-out as a function of effort-in.

But it's more than that. GameMaker in particular /forces/
kids to adopt a sophisticated object-oriented asynchronous
event-driven approach from the git-go. This is in contrast
to supposedly object-oriented languages like C++ which only
/offer/ OO features but don't /require/ anybody to use them.
And the typical introductory course, alas, skives off these
features. So a HS kid with a few weeks of experience with
GameMaker will be *more* sophisticated than most HS kids
coming out of a year of introductory programming classes.
Seriously, how many college seniors can reliably explain
what is meant by instantiating class X to form object Y?

Once upon a time I was giving the physics colloquium at
IBM Watson Research Lab, and during the Q&A period somebody
asked what I thought was the most significant computer-
related development of recent years. I said Visicalc (i.e.
spreadsheets). They were too polite to boo, but I knew
that the overwhelming majority of the audience vehemently
disagreed. I explained my rationale: Visicalc was
important because it increased by orders of magnitude the
number of people who were in control of their computer, in
the sense that they could tell it what to do, rather than
having it tell them what to do. Also I gave it props for
being highly original and being a strong departure from
the usual imperative programming model. (The functional
programming model is another departure, but it has a
/smaller/ user community, unlike spreadsheets which have
a /larger/ user community.)

The whole situation reminded me of a Gary Larson cartoon:
There are a couple of big dinosaurs. One is pointing,
sneering, and laughing at a small, scruffy mammal. The
other dinosaur has a puzzled look on his face as he holds
out a paw to catch a snowflake, not knowing what snow is
or what it portends.

Or perhaps an even closer analogy is to the time, not
too long before Visicalc, when it was considered macho
and sophisticated to program in assembly language,
whereas higher-level languages were for wimps.

My point is that what is considered "mainstream" and
"sophisticated" now isn't going to be considered either
mainstream or sophisticated in the future.