Gas station without pumps

2017 April 11

Co-instructor wanted for applied electronics course

Filed under: Circuits course — gasstationwithoutpumps @ 22:04
Tags: ,

I am looking for someone to be a co-instructor with me for the Applied Electronics for Bioengineers course at UCSC next year (January 2018–june 2018).  There are two reasons for my wanting a co-instructor:

  • I want to train someone to take the course over from me when I retire (in about 3–4 years).  Right now, I’m the only person who has ever taught the course, and there are no other faculty at UCSC particularly interested in taking it over. My department has no other faculty who know enough electronics, and the EE and CMPE departments are having enough difficulty covering their own courses, so I need to find someone from outside our usual faculty.
  • The course is expected to grow to 100 students next year, and I can barely handle the grading load and lab supervision for 70 students this year (71–73 students last quarter, 68 students this quarter).  If I could split the grading load with another person, we would each have a large, but manageable load.  I might be able to hire undergrad graders to do the homework grading, but not the lab reports, which require good feedback on the writing.

I’ll be hiring undergraduates to help answer questions in the lab, as I’ve been doing this year, but I would want the co-instructor to be present for about half the lab sections.  I think that we’ll have 5 sections of 20 students each, so I’d do 2, then we’d do one together, then the co-instructor would do 2.  The total number of hours a week would be about 3.5 attending/giving lectures, 9.5 hours lab, 8 hours grading, for about 21 hours a week.  I don’t know what the pay would be (depends on qualifications on paper), but the pay would probably be meager by engineering standards—I’d guess it would work out to about $40/hour, though it might be more if the lab time is properly accounted for in the pay rate.

If any of my local readers are interested in the possibility of being a co-instructor, please contact me (karplus@soe.ucsc.edu).  If you know someone who might be interested, please pass on the information.

 

2017 February 27

Understanding semilog plots

Filed under: Circuits course — gasstationwithoutpumps @ 10:22
Tags: , , ,

I realized in doing the homework grading this weekend that few of the students in my electronics course had any intuitive understanding of semilog plots (that is, plots in which one axis is linear and the other logarithmic).  I had been assuming that providing the following plot

Forward voltage as a function of current for a 1N914BTR diode.

Forward voltage as a function of current for a 1N914BTR diode.

would let students see that the voltage grows approximately with the logarithm of the current, and that means that a voltage difference corresponds to a current ratio. Very few students got that from the picture, the formulas, or the description in the text. They almost all wanted to pretend that the diode was a linear device with voltage proportional to current (i.e., that it was a resistor), so that a 6% change in current would result in a 6% change in voltage.  The whole point of using the diode was to introduce the exponential non-linearity, so this confusion definitely needs to be cleared up.

I was going to try to explain semilog plots and exponential/logarithmic relationships in class today, but my cold has gotten so bad that I had to cancel class today. That means I have another 2 days to figure out how to explain the concepts. If any of my readers can think of ways to get students to interpret semilog plots correctly, please let me know. I think that the relationships are too obvious to me for me to help students past their misunderstandings—I can’t get far enough into their mindsets to lead them out of confusion.

2016 November 3

Writing feedback

Filed under: Uncategorized — gasstationwithoutpumps @ 09:15
Tags: , ,

In his post Omics! Omics!: 10 Years of Omicing!, which reflects on the influences on his writing, Keith Robison says

The other person who deserves nearly infinite credit for making me think about my word choices is my father.  Sometimes he strays into being a pedant and enforcing rules which have fallen by the wayside, but he did make me think when I spoke and wrote.  I’ve seen some guidelines for helping students that counsel picking only a few major errors to mark, for fear of scarring the psyche of young writers.  Dad didn’t subscribe to that viewpoint in the least, and I’m the better for it.  In high school I treasured getting back a draft with red ink all over it; it’s a service I missed in college and beyond.  That meant he had read it and thought about it, and my work was always better for it.

I think that this attitude is one that we need to see more of, both among students and among faculty. I put a lot of time into trying to provide thorough feedback on student writing, even though I know that it is not always appreciated.  I also know a number of faculty who bemoan the low quality of student writing, but spend almost no time giving detailed feedback so that the students can improve.

There are times for triage—concentrating on the students whose work could benefit most from editing, while providing only minimal feedback to those who produce word salad or whose writing is very good—but I prefer to try to provide similar amounts of feedback for all students.  For the word-salad students, my comments are mainly on sentence structure and paragraph structure, to try to have their writing make sense at least at a local level. The students in the middle get a mixture of different comments from punctuation to overall structure of the paper, while the top students get mainly get comments on trivial little details that can polish their already good writing.

2016 September 20

Trick for encouraging cooperation

Filed under: Uncategorized — gasstationwithoutpumps @ 15:26
Tags: , ,

Adam Grant, a professor at the Wharton School of the University of Pennsylvania, provided an interesting technique for encouraging cooperation in his business-school classes (a culture noted for cut-throat competition between students):

How could I get students to help one another?

Four years ago, I found a way. The most difficult section of my final exam was multiple choice. I told the students that they could pick the one question about which they were most unsure, and write down the name of a classmate who might know the answer — the equivalent of a lifeline on the game show “Who Wants to Be a Millionaire?” If the classmate got it right, they would both earn the points.

Essentially, I was trying to build a collaborative culture with a reward system where one person’s success benefited someone else. It was a small offering — two points on a 120-point exam — but it made a big difference. More students started studying together in small groups, then the groups started pooling their knowledge.

You can read more about his attempts to encourage student cooperation in Why We Should Stop Grading Students on a Curve, published in the New York Times.

I don’t think I can use this exact technique, as none of the courses I teach involve exams—all are graded on the written reports that students write.  I could use it for homework, I suppose, but the overhead of checking other student’s responses might increase the turnaround time for homework grading.  I’m also already seeing more cooperation on the homework than I really want.

Furthermore, students quickly learn who the best student in the class is, and would just point to him or her, with no increase in useful cooperation.  So I think this technique would only work in student cultures that currently have a high degree of secretiveness and competition, not in already collaborative cultures.

2016 August 12

Playing with Nao humanoid robot

Filed under: Robotics — gasstationwithoutpumps @ 11:09
Tags: , , , ,

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.

 

Next Page »

Blog at WordPress.com.

%d bloggers like this: