Playing with Nao humanoid robot

Yesterday I had an opportunity to play with a Nao robot in a three-hour workshop at UCSC, run by Dr. Denise Szecsei of the University of Iowa. I found out about the workshops through an article in Santa Cruz Tech Beat, an on-line publication about local tech events. (Santa Cruz Tech Beat is worth reading, with a high signal-to-noise ratio and only about 30 articles a month.)

The basic idea that Denise was pushing is the use of the Nao robots in introductory programming courses—she created a course at the University of Iowa called Dancing Robots that supposedly been successful in recruiting women into programming courses there (she did not give us detailed information, as the focus of the workshop was on getting us to experience programming the robots, not on academic justification). She was also looking for collaborators on either educational projects or art projects, so was glad to have some grad students from the Digital Arts and New Media project at the workshop.

You can see an example of the results of the dancing robots courses on YouTube:

I’ve always thought that the Nao robots were cute, but at $9000 from the US distributor RobotsLab (and $890/year for warranty), they are too expensive for me to buy as a toy.  So I welcomed the chance to play with one for 3 hours.

What the workshop was intended to be was a brief tutorial on Choreographe, the drag-and-drop scripting environment for the robots. That environment looks ok to use, with simple message passing along wires to trigger pre-written boxes for actions like “say” or “timeline” animation.  Most of the dancing work is done by using the timeline like stop-frame animation (at 25 “frames” per second), with the software interpolating between target poses.  The target poses are created by physically manipulating the robot, making the whole process accessible to 6th graders (though the fragility and cost of the robots makes me think that you would need careful supervision even for high-school and college students).

I was not interested in the dance aspects of the robots, so I worked with one of the workshop staff (Denise’s son) on diving into the Python SDK (there are also C++, Java, and JavaScript interfaces, but the Python one is best integrated with Choreographe and the best for rapid prototyping, which is all I had time for). I spent a little time the night before the workshop looking at the programming interface (which I did not really understand from the quick glances at the documentation) and at the capabilities of the robot in terms of sensors and actuators.

What I wanted to do was to program one action—shifting the weight of the robot onto one leg, then picking up the other leg, so that the robot stood on one foot.  I planned to do the weight shifting by coordinated motion of the hip roll and ankle roll actuators.  Initially, I had thought to do it on just one leg, but I ended up doing it on both legs, since the starting position had the feet approximately the hip distance apart, so rotating both hip-roll actuators one way and both ankle-roll actuators the other way results in a parallelogram linkage, with the hips and torso staying level while moving sideways.

To detect the weight shift, I used the force resistors in the foot.  There are several ways to access them through getData() calls: the processed “leftFootTotalWeight” and “Device/SubDeviceList/LFoot/FSR/TotalWeight/Sensor/Value”  or the raw sensor values “Device/SubDeviceList/LFoot/FSR/FrontLeft/Sensor/Value”, … .  I ended up using “leftFootTotalWeight” or “rightFootTotalWeight”.  The basic idea was to start a thread running moving the hips far to the left, and set up an interrupt routine triggered by the event footContactChanged. When that event fired, I checked the weight on the right foot, and stopped the motion if the weight was low enough (I think I used 300g, since the unloaded force resistor with the foot in the air was reporting something like 200g).

I did not have time to add a further refinement to the weight shift, to adjust the weight to be centered over the supporting foot, using the center of pressure sensor. I had the robot speak the values of that sensor, but did not use it to tweak the hip and ankle angles of the supporting leg.

Once the weight had been shifted on the left leg, I had Nao pick up the right leg by adjusting the hip pitch, knee pitch, and ankle pitch of that leg.  The posing software in Choreographe made it fairly easy to figure out what the correct signs were for the angles and for picking target values. The robot lurched a little bit as the right foot was picked up, probably because the foot had not been fully unweighted, but possibly because of the foot not being lifted quite vertically.

If I’d had more time, I would have done the centering of the weight over the supporting leg before lifting the other foot. I would also have moved the motion of the supporting foot into a separate script, so that different gestures could be made from the one-legged stance. In doing that, I’d probably want to have any one-legged boxes run a balancing thread to keep the weight centered over the supporting foot, so that sticking out an arm or a leg doesn’t topple the robot. Either that, or have a one-legged balance box that is runs in parallel with any gesture actions.  It would probably take me a day or two of programming to create one-legged action boxes robust enough for someone else to use them, and probably a few weeks of use testing before they would be worth adding to Choreographe.

Working with the robots definitely needs two people, as one person needs to spot the robot any time it is moving (remember, fragile and expensive!).

It was very useful working with someone familiar with part of the programming interface, so that I did not have to waste much time figuring out how to create a new box or test it out. He was the one who suggested outputting a string to pass into a “say” box for reporting the foot sensor values for debugging, for example. I started out just reading the sensors and reporting the weight, then tried figuring out how to interrupt an ongoing motion by raising one arm very slowly, to be interrupted by any of the touch sensors. Once I had the basics of starting a parallel thread and stopping it on an interrupt, I programmed the weight shift. Once that was working I added lifting and lowering the non-supporting leg.

I fully expected that the spotter would be called on to catch the robot as it fell during my development of the program, but despite a little worrisome lurching as the unweighted foot was lifted, the robot never toppled.

I doubt that the Python SDK is fast enough to do a closed-loop feedback system for balance, but it was certainly good enough for a slow weight shift onto a single leg, and the feet are wide enough that no dynamic balancing was needed. It would be a fun programming environment for a Python course, as long as the students were into humanoid robotics.

The Choreographe environment provides a reasonable interface for fairly simple sequencing and synchronization, but I suspect one hits its limits pretty soon. Being able to create new blocks rapidly, by copying existing blocks and editing the Python in them, makes the system a lot more powerful, though I got the impression that the “Dancing Robots” courses rarely get that far.

The Nao robots were, as I expected, a lot of fun, but I couldn’t really recommend them for a beginning programming class. At $9000 for each pair of students, they are way too expensive and way too fragile.  For beginning programmers, you really want things that students don’t have to worry about breaking if they make a little mistake. One can get fun robot toys for students to program for $100 each, since wheeled robots are much cheaper and easier to make than humanoid ones. Not only is the financial risk lower with cheap robots, but they can be made much more robust (though educational robots needn’t be made to sturdiness required of combat bots).

To break into the consumer market or school market, I think that Nao would have to come down in price by about a factor of 10, which would be difficult to manage, given what the robots contain.  There are 24 actuators (2 head, 6 in each arm, 6 in each leg), plus cameras, ultrasonic range finder, touch sensors, foot pressure sensors (4 per foot), gyroscope, accelerometer, LEDs, … . The motors and 12-bit joint angle sensors (magnetic rotary encoders) alone probably cost close to $1000.

 

Advice for CS students

Katrin Becker has collected advice from senior computer science students to those just starting out, which she has collected in her blog post Worth Sharing: Advice for New Students From Those Who Know (Old Students).   She summarizes the list as follows:

Top 10 list [Highlights]

• Start Assignments Early: they will take longer than you think.
• Make friends.
• Ask questions.
• Practice Programming. Try Stuff.
• Make sure Computer Science is really what you want to do.
• Choose options you will enjoy.
• Go to class.
• Don’t take too many CPSC courses in one semester.
• Plan your programs on paper before you start typing.
• Remember to have fun.

and goes on to give specific quotes from students for each of these categories (plus some other unsorted quotes).  Some of my favorites include

Be nice to people. You never know when they will be able to help (or hinder) you in the future.

You’ll enjoy it more if you treat your work as a full-time hobby, and not just a path to a job.

Working in groups tends to be harder, not easier.

Of course, a lot of the advice applies to any engineering major, and some to any college major.  Even the advice about programming applies to other design tasks.

A seat at the table

Mark Guzdial in #Gamergate as a response to re-engineering: BPC as a conspiracy to change computing wrote

We in the Broadening Participation in Computing (BPC) community are aiming to achieve a similar kind of social engineering that the Gamergate supporters are complaining about. I am part of a vast, international (though maybe not particularly well-organized) conspiracy to change computing culture and to invade computing with many women and members of under-represented groups. We are “actively plotting to influence” computing. The Gamergate supporters argue that the conspiracy is about “artistic aspirations.” In BPC, we say that we’re about social justice, equity, and diversity. From the perspective of the “engineered,” the difference in purpose may not make much difference. One of the pushbacks on the call I shared to eliminate nerd culture was, “Can’t we just shape/change nerd culture?” Do the nerds want to be changed?

What might a response to BPC look like? Might well-prepared, privileged male and white/asian CS students complain about efforts to give seats in classes to women or under-represented minorities whom they may perceive as less-prepared?

I have no objection to giving seats in classes to anyone capable of  learning the material, but I believe that this needs to be done by increasing the number of seats, not taking them away from other students.  I’m all in favor of expanding the pipeline, but not of holding back those who have already started on the path, so that others can “catch up”.

There’s a general awareness that there’s a problem, but there’s less conviction that it’s an important problem or that there’s an obvious way forward to fixing it.

I agree that the problem of gender imbalance and racial imbalance in CS is an important one, but I’m less convinced than Mark that there is an obvious, equitable way to fix the problem. He seems to think that lotteries are the way to go:

In NPR When Women Stopped Coding in 1980′s: As we repeat the same mistakes, Mark wrote

I understand why caps are going into place. We can’t support all these students, and there are no additional resources coming. What else can CS departments do? We might think about a lottery or using something beyond CS GPA to get those seats, something that’s more equitable.

I disagree with him strongly on this. I responded on Mark’s post with the following comment:

I’m not sure that I agree with “We can’t support all these students, and there are no additional resources coming. What else can CS departments do? We might think about a lottery or using something beyond CS GPA to get those seats, something that’s more equitable.”

Granting access to a limited resource to those whose prior achievement is highest seems to me to be highly equitable. Denying higher achievers because they are of the wrong race or gender does not.

Increasing the resources available for teaching, so that we don’t have to restrict who majors in a field seems like a good strategy, as does providing slower on-ramps for those who did not have good early training. But denying entrance to those who may have dedicated their lives to the field, just because others did not have (or did not take) the opportunity to reach that level of achievement—that does not seem “equitable” to me.

Note: I may be biased here, because my son is a white male majoring in computer science who has been doing recreational programming as a major activity since he was 10 years old. I would be very offended if he had to win a slot in the major by a lottery—college admissions alone is enough of a lottery these days.

Are we then to tell students not to form any intellectual passions in middle school or high school, because doing so will get them labeled as “privileged” and denied further opportunity? Or should they only form passions for things that no one cares about, so that no one will try to take their passions away from them?

Although I’m not fond of sports analogies, it is common for people to point out the absurdity of the lottery position by suggesting that the same be applied to sports teams. The football teams at the Big 10 schools should not consist of those privileged athletes who started young, got the best training, and had the best performance in high schools, but should be assigned by lottery to anyone who is interested in playing, even if they have never picked up a football in their lives. Why should only those who had the good fortune to be large, fast, and strong be allowed to play?

Michael S. Kirkpatrick countered my comment with

It’s often so hard to be objective when it comes to perceptions of equity. As Anatole France observed, “In its majestic equality, the law forbids rich and poor alike to sleep under bridges, beg in the streets, and steal loaves of bread.” The open question is whether those students truly are higher achievers, or if they are just starting from an advantageous position. In that case, would it not be more equitable to give the opportunity for students who did not have prior opportunities?

His argument makes the assumption that primary goal of college education is a social justice function—to provide opportunity for those who have not previously had it. While a generous impulse, this philosophy taken to extremes results in eliminating grad schools and upper-division courses to create more freshman courses, and even replacing freshman courses with remedial courses, resulting in college as very expensive high school (or, in the case of some athletes in scandal-ridden schools, grade school).  Increasing opportunity is a great thing, but it shouldn’t be allowed to kill off the other great things about universities: like the opportunity for people to stretch their minds to the limit, to share ideas with other intelligent and passionate people, and to advance the state of the art. While universities do serve an important role in aiding social mobility, it is not, in fact, their primary function in society.

A variant of Kirkpatrick’s argument has often been used to kill off gifted education in public schools (because of a correlation between socio-economic status and identification for gifted programs)—forcing the parents of gifted students to take on educating their children themselves, which only the wealthy (or upper middle class) can easily afford to do. This approach increases the disparity between the wealthy and the poor, as the gifted students with less wealthy parents get much more limited educations—defeating the original goals of “equity” that killed off the public programs for gifted students.

There are good reasons why many parents of gifted kids started referring to “No Child Left Behind” as “No Child Allowed Ahead”, as it was much easier for schools to reduce their achievement gaps by slowing down the students who were learning fastest than by speeding up those learning slowest. Guzdial’s approach to rationing CS education seems to be following the same model.

Bonnie responded to Guzdial’s post with comments about what her college is doing to broaden participation, speaking both of successes and failures, and ending with

I just don’t know how we can make up for the poor education they received in K12. And that, I think, is where the true inequity lies.

Here I agree with Bonnie—if the problem is that some students get support early and others get support late, the solution is not to slam the door in the faces of those who got early support, but try to extend early support to more people. For that matter, I’m not in favor of slamming the door shut on anyone.  I don’t buy Guzdial’s assumption that this is a zero-sum game and that the only way we can have more women and URMs in CS is to have fewer white or Asian males. I think that there is plenty of room in the tent still for everyone who is interested and willing to work at learning the material.  We should not be rationing education, but providing enough education that everyone can get as much as they want.

In response to a different commenter, Guzdial wrote

We’re not talking about employees, Ian. We’re talking about seats at the table for students. If you get more women and under-represented minorities enthused about CS, there are still not enough seats at the table. If we’re going to allocate seats based on current ability, we have to get women and URM students to be better than privileged white boys. That’s a really high bar.

You may be under the misconception that computing is a meritocracy. It’s not. It’s not those with the most merit. It’s those with the most privilege.

It is almost certainly true the computer industry is not a meritocracy—but we should be trying to make it one, not rationing out education like butter in WW II. If there are not enough seats at the table, then buy a bigger table with more chairs! That will cost less in the long run than squabbling over who gets seated now.

Details matter

In a comment on Mark Guzdial’s blog post Pushback in California on Computing in Schools, “lizaloop” wrote

2. While I support the effort to bring programming into schools I’d like to see us also emphasize the concept of each person taking charge of his or her own learning. Because programming languages change so rapidly anyone who intends to do serious coding will have to repeat the learning process over and over. Our introductory CS classes need to focus more on “learning how to learn” than on the specifics of any one coding language.

While it is certainly true that programing languages go in and out of fashion (where are the COBOL programmers of my youth now?), and it is also true that people need to keep learning if they want to remain in any technical field for long, that doesn’t mean that intro CS courses should give up on teaching specifics and instead tackle the nebulous goal of “learning how to learn”.

In fact, one of the things that distinguishes computer programming from many other courses of study is that you must learn the specifics of the programming language and tools you are using if you are to get anything done.  “Big picture” thinking does not get programs written.  It does you no good to “learn how to learn”, if you then don’t learn any of the details.

One of the major things that students new to computer programming (and to other engineering fields) need to learn is that details matter.  The specifics of the computer programming language they are learning matter—not forever, since they might never use that particular programming language again—but while they are doing what they are doing right now, the details matter.  That is an enduring, transferable lesson, but it depends on having a course in which the specifics of the coding language are viewed as important.

Of course, this does not mean that the teacher has to spend a lot of time on the details—the compiler or interpreter will make it abundantly clear to the students that details matter.  But the teacher can strengthen or weaken that lesson by their own example and by their grading.  Teachers who only do sloppy pseudocode on the board, never filling in the missing details or correcting mistakes, will convey the impression that the details are unimportant.  Teachers who don’t mark down sign errors, punctuation errors, and off-by-one errors in quiz or exam answers also give the impression that “close is good enough”, which is emphatically not the case in real programming.  Teachers who never read their students’ programs, but only do crude I/O testing to grade programs, will give the impression that documentation doesn’t matter.

On the other hand, teachers who spend all their time fussing over semicolons and never talking about the bigger ideas of algorithms, data structures, problem decomposition, and program documentation will produce low-quality copy editors, not programmers. One reason I like Python as a pedagogic language is that the syntax is simpler than many other languages, so that I can get the details right without having to spend so much time explaining the details (and the students can spend more time on more interesting debugging than chasing down punctuation errors).

But I’m not trying to dump on lizaloop’s ideas entirely.  Computer programming courses are a good place to teach students to “learn how to learn”, though not by ignoring the specifics and following some sort of touchy-feely metacognition curriculum.  Indeed, it is because of the specific details that students must master to get anything done that programming is such a good subject for learning how to learn.

Those specifics are essential to the task at hand (not some nebulous future need that is all most math or science classes manage), but they are easily looked up in on-line documentation with generic Google searches.  Try googling things like python reverse string, HTML color, or c++ function pointer to see how easy it is to get online tutorials and documentation on specific details.

It is completely reasonable for a teacher to give students concepts and keywords, but expect them to look up some of the details for themselves.  For example, a teacher might explain RGB color space and how colors are often encoded as three one-byte numbers in hexadecimal format, but not give any specific color codes, expecting students to find the codes they need either by experimentation or by on-line search.

In the approach I’m suggesting, the students are still focused on the details of the coding language, but they are also learning how to learn (at least at the lowest level of learning how to look up specific facts).

Teaching students how to learn more complex concepts on their own (like how to choose which color space to work in) is probably a forlorn hope, but getting them to learn to look up specific facts (like how to transform from HSV color space to RGB color space) and low-level details (like HTML color codes or how to reverse a string in Python) is certainly a reasonable expectation for an intro CS course.

ScratchJr

If you’ve been wanting to teach your child to program, but found Scratch too complicated for your 5-year-old, there is a new option: ScratchJr.

On the  ScratchJr – About page, the developers say

What is ScratchJr?

ScratchJr is an introductory programming language that enables young children (ages 5-7) to create their own interactive stories and games. Children snap together graphical programming blocks to make characters move, jump, dance, and sing. Children can modify characters in the paint editor, add their own voices and sounds, even insert photos of themselves—then use the programming blocks to make their characters come to life.

ScratchJr was inspired by the popular Scratch programming language (http://scratch.mit.edu), used by millions of young people (ages 8 and up) around the world. In creating ScratchJr, we redesigned the interface and programming language to make them developmentally appropriate for younger children, carefully designing features to match young children’s cognitive, personal, social, and emotional development.

ScratchJr is now available as a free iPad app. We expect to release an Android version later in 2014 and a web-based version in 2015.

Unfortunately, I can’t give you a review of the program, as I don’t have an iPad to check it out on (nor do I have easy access to 5-year-olds, now that my son has grown up).  They did a great job on Scratch, though, so I would hope that ScratchJr has extended the concepts to a lower age group appropriately.