Gas station without pumps

2013 December 23

Different levels of the “same” course

Filed under: Uncategorized — gasstationwithoutpumps @ 12:46
Tags: , , , ,

In thinking about the redesign of the bioengineering curriculum, I’ve had to pay a lot of attention to what level of courses the engineers would be required to take.  Our campus offers physics at three different levels (one algebra-based, the other two calculus-based) and calculus at 4 levels (honors for math majors, for physicists and engineers, for life scientists, and for economists). Do I allow the students to take either of the calculus-based physics courses? Do I allow any of the three calculus classes (excluding the one for economics majors)?  I’ve wrestled with this problem for a while (see for example, my post Physics for life-sciences majors from last June).

In favor of allowing the lower level courses:

Usually there is the most scheduling flexibility for the second-lowest level—the level aimed at biology majors—because that is where the largest numbers of students are, so the courses get offered repeatedly during the year, while the more advanced courses get offered only once.  So from a scheduling standpoint, it would be best if students were able to take those courses.

In bioengineering, we also get a lot of students who start out in biology, but who later realize that other majors are more interesting (freshman year everyone thinks they want to go to med school—most have given no thought at all to engineering).  Because the biology majors are advised to take the calculus and physics courses intended for biologists, the students have taken only those and not the higher level calculus and physics courses intended for engineers.  So a change of major is easier if students are allowed to take the biology-level calculus and physics.

One thing I’m trying hard to avoid in the bioengineering curriculum redesign is “creeping prerequitism”—the tendency for most courses to gradually increase the prerequisites in order to have better prepared students in the course.  In many cases the prerequisites are irrelevant to the material of the course (like multi-variable calculus for a data structures course or genetics for a cell biology course), but are just filter prereqs, to make sure the students have more “maturity” by having passed a gantlet of other course.  Because of these prerequisites (both real ones and filter ones) being added independently by each of the 8 or 9 departments that teach courses required for bioengineers, we end up with a program grossly overloaded with lower-division “preparation” courses, and not enough upper-division “application” courses.

Against allowing the lower-level courses:

In exit interviews with seniors last spring and this fall, we asked them about their experiences in calculus and physics.  Those who had taken the lower level of calculus-based physics course felt that it had been a waster of their time—neither their classmates nor their professors seemed to care much about whether the material was learned, and everything was covered rather superficially.  (We didn’t get the same info about calculus, because most had been forced to retake the higher-level calculus class if they had only taken the biology-level one.)  So from a pedagogic standpoint the students get a better course if they take the higher level with students who expect to use the material and with professors who expect their own majors to be taking the course.

Some upper-division courses do rely on math and physics skills of the more advanced courses.  For example, the upper-division probability and statistical inference classes do rely on students being adept at integration, the statics and dynamics course relies on students knowing Newtonian mechanics well and being able to handle differential equations, and the electronics courses require some skill with calculus and differential equations.

Concluding thoughts

I read an blog post today by a high-school physics teacher addressing a similar question at the high-school level: Jacobs Physics: How do you tell the difference between AP and “regular” physics?.  He doesn’t have to face what courses students are required to take, but only which ones they should be advised to take, but the underlying questions are the same. In the post, Greg Jacobs writes

If an AP and a Regular course cover the same “standards,” how are the two classes different?

Don’t use standards to define courses; use tests and exams, preferably as written by someone external to the course, to define courses.  Once you’re clear on the level, topics, and depth of question that your students will be expected to answer, then you can make up a concordance with any state standards you need to.

The AP Physics 1 exam covers much of the same material as regular/Regents. The major difference is the depth of that coverage, as evidenced in the test questions.

A regular question can generally be categorized in a single topic area, and can be answered in one step, or two brief steps, or a one-two sentence explanation with reference to a single fact of physics.

An AP question generally requires cross-categorization across two or three topic areas. Most require multi-step reasoning, or a two-three sentence explanation with reference to more than just one fact of physics. AP questions, for the most part, require students to make connections across skills and topics.

As an additional comparison, you might consider a conceptual class. Conceptual Physics can cover many of the same topics as “regular” physics, but without using a calculator.  …  A conceptual approach provides a greater contrast between AP and non-AP physics.

The key idea here is that the difference between levels is not in what subjects are covered, but in the expected skills of the students after taking the course. That holds true at the college level as well—I can’t decide based just on catalog copy what level of course students need, because the catalog copy only lists topics, not the complexity of the problems that students who pass will be able to solve.

In the interest of minimizing filter prereqs, but making sure that all genuine prereqs are met, I’m suggesting requiring the higher level for the bioelectronics and assistive technology: motor tracks, but allowing the lower calculus-based physics for the biomolecular and assistive technology: cognitive/perceptual tracks.  I am suggesting requiring the physicist/engineer track for calculus in all tracks, since it is needed for a higher-level course in all of them. It’s not the same course in each track, but electronics, statics and dynamics, and statistical inference all require greater facility with calculus than the calculus-for-biologists track provides.

2013 August 4

Units in physics again

Filed under: Uncategorized — gasstationwithoutpumps @ 17:22
Tags: , , ,

Joe Redish has a series of posts on The Unabashed Academic on the use of units in math and physics courses: Units and stoichiometry, Cutting mathematicians some slackTeaching units, and A higher power—units again.  I just re-read that series of articles today (having read one or more of them when they first came out).

The Teaching units post had one paragraph that particularly caught my attention:

In addition to suppressing units when we do pure math, we might also note that when writing computer code we often suppress units. (This led to a multi-million dollar failure at NASA.) But any object-oriented programming language can correctly retain (and even check) units. I doubt that classes in computation, either in computer science, engineering, or physics departments, teach objects with units—despite the fact that it would be incredibly useful for scientists.

I used Vpython with my son in learning calculus-based physics, and was irritated by its inability to play nicely with units (see Units in physics and Physics simulations). It would be a fairly simple modification to Vpython to allow a “units” option for each plotting or drawing routine  There could be a global option to change the defaults from None (for legacy Vpython code) to “m” for lengths, “s” for time, and “Hz” for frequencies (like the “rate” function), and to require units using the Unum package for all plotting and drawing.

For teaching physics, having unit checks on all computations would help students debug both their programs and their physics understanding.  I really don’t understand why this was not included from the beginning in Vpython, since the language was intended for use as a language for teaching physics. Carrying the units around like this does slow the code down (perhaps by a factor of two), but the pedagogical value of being able to debug incorrect-unit bugs far exceeds the pedagogical value of faster simulations.

Next year, in the circuits course, I’m going to be a stickler about students always including units in their computations, as a consistency check on their thinking, since many of the bioengineers do not have good number sense or algebraic intuition.  Forcing them to carry units throughout may make them a little less likely to do random algebraic manipulations.

2013 July 4

Caballero on teaching physics with computation

Yesterday, Danny Caballero left a comment on my blog with pointers to three preprints of papers he’s been a co-author on:

I couldn’t agree more with the overall sentiment in this post. Computing is important for all students of science and for science teachers. However, as you say, I do think my dissertation work has been misconstrued a bit in this post. So, let me clarify.

The inventory you mention measures a small slice of mechanics taught in introductory physics. It’s been an important slice, but maybe now it’s time to think beyond it. What are students learning above and beyond this assessment? In M&I, they are learning about modeling, computing, and connecting the two. My work shows that the present implementation of M&I doesn’t produce great gains on this assessment, that students make mistakes in their code, and that they are less inclined towards computing after instruction.

So what? We are getting to teach students how science is done and they are using computing to investigate models. Now, this implementation is not the most polished one, which means we have a good way to go. But, that’s OK, because we are not going to fix all these issues overnight. We have been working on them for the last two years in various contexts. But, we need to figure out how to teach science and computing together. And we need to figure out how to do it well.

So, I’ll point you to a few other publications on computing in physics that I’ve written. Two concern high school, and another deals with physics majors. The high school work shows we can implement ideas from my dissertation work at the high school level (as others are doing). Moreover, we find that students who know physics and computing ideas can make good models of systems and are not memorizing lines of code. In my dissertation work, we didn’t do any qualitative work like student interviews, but it’s clear that doing so is necessary. The work with physics majors is one of the first forays into integrating computing in upper-division physics. We show that a new model for implementation can positively affect student attitudes.

High School:
http://arxiv.org/abs/1207.0844
http://arxiv.org/abs/1207.1764

Upper-division:
http://arxiv.org/abs/1303.4355

This morning I read his three papers.  They all describe prototype courses that use computational modeling to teach physics, with some analysis of the outcomes.  They are not controlled experiments, but prototyping proof-of-principle projects (as are most educational research “experiments”).  This is not a criticism of the papers—one generally has to do a lot of prototyping before arriving at a method that is robust and repeatable enough to be worth the difficulty and expense of controlled experiments.  Engineers see the need for prototyping, but too many people in other fields think that things have to work perfectly the first time or be discarded forever.

These papers bracket the previous work Danny did that studied computational modeling for first-year calculus-based physics.  The two high-school papers are about a 9th grade physics class that uses the Modeling Instruction approach to teaching physics, to which was added computational modeling using VPython.  The “upper-division” paper discusses adding computational modeling to a 2nd-year classical mechanics course for physics majors, following a traditional 1st-year calculus-based physics course.

I was a little unclear on the level of the 9th-grade course.  In one place he refers to it as “conceptual physics”, but in other parts of the description it sounds more like an algebra-based high school physics course (covering the mechanics half of AP Physics B), a step-up from conceptual physics.

From his description, it seemed fairly straightforward to add a computational component to the Modeling Instruction approach, and it helped students see that all the different “models” taught in that approach are really special cases of the same underlying general model.  They used Vpython with a couple of additional packages (PhysKit and PhysUtil) to make creating graphs and motion diagrams easier for beginning programmers.  The additional packages allow lines like

    motionMap.update(t)
    timerDisplay.update(t)
    graph.plot(t, cart.pos.x)

in the inner loop, simplifying the usual VPython interface a bit.

It sounds like the students were finishing the course with a mix of students who knew what they were doing and those who still hadn’t quite grasped the physics or hadn’t quite got the programming.  He did try analyzing some of the student work to see whether students were having difficulty with the physics or VPython for making the simulations, but I found the results hard to interpret—raw numbers don’t mean much to me, because I don’t have a good prior expectation of what 9th graders at a private high school should be able to do.  I’m curious whether difficulties with programming correlated with difficulties in understanding the physics, and whether grading the computational homework gave insight into the misconceptions the students had about the physics.

One of the strong points of the computational approach is that it allowed the students to model phenomena usually beyond the scope of 9th-grade physics (like a soccer ball with linear drag forces).  I found this to be the case for calculus-based physics also, where we modeled pendulums without the small-angle approximation (problem 4.P.89 in Matter and Interactions) and the magnetic field lines of a helical solenoid.

Some of his observations are unsurprising: “Students find debugging their programs difficult; that is, they have trouble determining whether they have made a coding error or a physics error and how to deal with that issue. ”  He also noticed that some students found installing the software difficult—I believe that the VPython developers have been working on that problem, though it is not yet at the level where all 9th graders will find it easy.

Personally, I’d like to see the physics simulations for high school students use computations with units throughout—this would help them catch a lot of their physics errors earlier.  I see this lack of units as one of the biggest flaws in VPython as an instructional tool for physics.  I’ve blogged about this before in Physics with Units, and I’ve done some VPython programming using Unum.  Unfortunately, the Vpython plotting and animation code does not play nicely with Unum, and having to strip out the units before plotting or drawing negates most of the advantages of keeping units around. I realize that for professional physics simulations, units are always implicit (in comments and variable names) rather than explicit, because that makes more efficient use of the computer, but for instructional purposes explicit units would be worth the inefficiency.

The 2nd-year classical mechanics course used Mathematica to solve ordinary differential equations (ODEs), and provided only minimal instruction in Mathematica.  The main improvement to the course from my perspective was the addition of a final project that allowed students to study an open-ended physics question of their own choice using computational modeling.  This improvement was discarded in subsequent offerings, because it required too much instructor time. Caballero wrote, “For junior and research-focused faculty, the computational project is a significant investment of their time and energy given the large enrollment in CM 1. Developing authentic, scientific experiences for students that can be sustained with little faculty input is challenging.”

This is a theme that I see repeatedly in course design in all disciplines and at most universities: the really good parts of prototype courses take a lot of instructor time and get discarded.  I think that the goal “sustained with little faculty input” is a wrong goal, but it is one shared by many faculty and administrators, who think that teaching is a burden that should be given as little effort as they can get away with. I’ve decided, rather deliberately, not to design my courses that way, but to design them around high faculty involvement.  I believe that the value of a University education depends on high-contact courses, and I’m willing to resist the MOOCification of the university at least in my own courses.  This does take a lot of my time, and I’ve given up on writing grant proposals to make the time—not a choice that most junior faculty could afford to make, given that promotion these days is based more on how much money is brought in than on the quality of teaching or research.

2013 July 1

How can we get more programming taught in high schools?

In the comments on Mark Guzdial’s post Why AP CS:Principles is a good thing: Responding to Gas Station without Pumps (which is a response to my post Millions for a fairly useless new test), an interesting question has arisen: What should a CS teacher know?

I commented

I agree that figuring out what content an intro CS teacher needs to know is important, both in depth and in breadth. If we set the bar too high, there will be no CS teachers in public schools (essentially the current situation). If we set the bar too low, no CS will be taught and we’ll have to undo the damage once the students get to college.

CS as a field is still struggling with how to teach beginners (it is pretty clear that some students learn, but it is not clear to me how much this correlates with what teachers do—but that’s your [that is, Mark Guzdial's] area of expertise, not mine).

Defining the core competencies that a beginning instructor of beginning students needs seems to me quite difficult. I suppose it starts with deciding what the students need to learn, then figuring out what the teacher needs to be able to do to get them there. I further suppose that this is the intent of the CS Principles course—figuring out the minimal set of essential skills we want out of a first course.

Garth commented

In most schools the CS teacher will also be teaching something else; Math, Science, Art or whatever so the requirements have to be realistic. I think CS Ed would almost have to be a minor, there are just not enough jobs out there yet for a teacher with only a CS Ed major.

So Garth has been thinking of it in terms of new teachers only, it seems. I suspect that we’d get more CS teachers more quickly by summer training for existing math and physics teachers than by trying to train new teachers in ed schools.

Physics teachers could be attracted to programming by a computational modeling curriculum, like the one used in the Matter and Interactions textbook.  Vpython provides a fairly simple entry point for physics teachers and students to write simulations of the sorts useful for AP Physics (both C: Mechanics and B).  I think that a computation-based text for Physics B still needs to be written, as Matter and Interactions definitely requires calculus after the first couple of weeks (or is there already an algebra-based physics book using something like Vpython?).  Once physics teachers become proficient in Vpython, it is not a big stretch for them to teach the CS Principles course (they could even continue to use Vpython for it).

Math teachers could be attracted to programming by summer workshops based around Project Euler, which provides a series of math challenges to be solved by programming (currently 434 such challenges).  Providing them with instruction in a suitable programming language (Python is a good choice for Project Euler) so that they can tackle the math problems would give them the experience programming needed before they would consider teaching programming.  Teaching them to program in Geogebra, free software for doing geometry and algebra presentations and apps, would also be valuable—both for improving their programming skills and for improving their current math courses.

The key point of both these ideas is that we could attract physics and math teachers to programming in order to become better teachers in their current fields.  That they would also become competent to teach beginning CS courses is a bonus.  Even if this approach failed to produce any new CS courses, we would still have improved physics and math teaching.  Given how addictive programming is, I think that we would also find these teachers becoming a force within their schools for creating programming courses, avoiding the current Catch-22: that there are no CS courses because there are no CS teachers, and no CS teachers because there are no courses.

I’ve not addressed in this post the initial question from the comments: what do beginning CS teachers need to know?  One implication of my proposal is that CS teachers need to be able to program.  They don’t need to be fantastically good programmers, nor do they need to know many different programming languages, but they need to be able to program and debug in the language of instruction.  They need to be able to model debugging, and they need to be able to assist students who are stuck (without taking over for the student).  They need to have personally done every assignment they assign, to figure out any ambiguities in the wording of the assignment and to make sure that it is doable with the tools and techniques that the students have been given in their class.

I think that may be enough—I don’t think that beginning CS teachers need to know software development techniques and the intricacies of the development environments and libraries beyond what is essential for the assignments.  They may choose to learn more (some math teachers might enjoy asymptotic analysis of algorithms, for example, and some physics teachers might get into programming robots), but it isn’t necessary for teaching an intro course.

I don’t think we can set the bar any lower: a teacher who can’t program can’t teach programming effectively, and programming should be at the heart of any intro CS course.

2013 June 30

Robots in physics

Filed under: Robotics — gasstationwithoutpumps @ 13:34
Tags: , , ,

I just watched the Global Physics Department of Matt Greenwolfe showing his use of Scribbler 2 robots as physics education tools.  See also Matt Greenwolfe’s blog, starting with The Robot Lab (formerly known as the Buggy Lab). It may be easier to get the content from the Matt’s blog posts than from the Global Physics Department recording, which had a lot of technical difficulties.

Scribbler 2 robot.  Picture copied from the Parallax web site that sells the robot.

Scribbler 2 robot. Picture copied from the Parallax web site that sells the robot.

He did some modifications to the code for the Scribbler 2 to provide precise control of the robots (1 mm/sec velocity and 1 mm/sec/sec acceleration accuracy) and made some nice graphical interfaces for students to control the robots with x vs. t, v vs. t, and a vs.t plots (plus one interface that does 2D motion).

One big problem with the Scribbler 2 was the limitation to about 18.5 cm/s velocity, which is pretty slow. The cool thing about them is that they have wheel encoders that allow 0.491 mm resolution with 507.4 counts per revolution. One limitation that is a complete deal killer for me is that the Scribbler 2 library is only available for Windows machines, so porting to a Mac platform would be a major effort.

I was looking to see whether one could easily build such a robot from easily available parts. One cool new part is an integrated wheel, motor, controller, and shaft encoder called the HUB-ee (available for $35 from SparkFun):

The HUB-ee is a type of robot servo but designed for wheels, in fact it is a wheel, but it is also a motor, a sensor and a motor controller. What’s that? Did we just blow your mind?
When you want to add wheels to your robot you would normally start with a whole collection of parts: The motor and gearbox, a motor driver board, and maybe some sensors for measuring wheel speed and a controller to count revolutions or provide closed loop speed control. Well, the folks over at Creative Robotics thought it would be handy if you could just buy a wheel that had all of those things built in, so they designed HUB-ee – just bolt it onto a chassis, apply power and away you go!
The HUB-ee is easy to mount, too! There are two threaded inserts for M3 bolts built in, there’s also a right angle bracket included for situations when you can’t go horizontal into the chassis. The mounting holes are even LEGO® lug compatible!! HUB-ee uses Micro-MaTch connectors to keep electrical connections tight and easily changed, check out the related items for mating connectors.

HUB-ee wheel picture copied from Sparkfun web page

HUB-ee wheel picture copied from Sparkfun web page, which says that images are licensed by CC BY-NC-SA 3.0.

The HUB-ee has a resolution of 128 counts per revolution of the wheel (1.473 mm resolution, 3× the step size of the Scribbler 2). The HUB-ee runs at 120rpm no load at 7v, which would be 37.7 cm/s, about twice the speed Matt reports for the Scribbler 2.

Although Matt reports 18.5 cm/s, the Parallax spec for the Scribbler 2 claims up to 80RPM, which would be 33.2 cm/sec, but that is probably with a 12V power source, rather than 6AA batteries. I suspect that Matt’s need for very precise control and operation with batteries limited the top speed he could use.  He does say that he would have liked a voltage controller (which would have added a $3–15 part cost to the robot, so a $7–40 increase in retail cost, based on the designs by TI’s WebBench tool or the PTN78000W module from TI) in order to have better speed control without having to worry so much about keeping the batteries fully charged.

The Hub-EE takes up several pins on a microcontroller (1 PWM pin, 2 output pins to control direction, 2 input pins for the quadrature encoder feedback) in addition to power and ground.  Two HUB-ee wheels would cost $70 and use 10 pins on a microcontroller—doable with an Arduino, but not leaving a lot of pins for other functions like sensor inputs.  There aren’t enough interrupt pins on the standard Arduinos to have all 4 wheel encoder pins triggering interrupts (which would be the highest-precision way to use the feedback information to get precise motor control).

Internally, the HUB-ee wheels use a Toshiba TB6593FNG motor controller, an H-bridge designed to work with 1.0A average current, with an on-resistance of about 0.35Ω for the output low.  The Toshiba data sheet doesn’t give the on-resistance of for high voltages directly, but if I’m interpreting their “Vsat” parameter directly, the on-resistance for each leg is about 0.5Ω, about a sixth that of the popular L293D H-bridges.  At under $3 a H-bridge (in single units), the TB6593FNG does not look like a bad choice for a small H-bridge.

Of course, to use the HUB-ee, one would have to build the rest of the robot (chassis, microcontroller, battery, … ). The Hub-EE is designed to mount to Lego beams, which could make chassis building easy, at least for prototyping.

I wonder whether, in a couple of years, we’ll be seeing integrated wheel units like the HUB-ee with an SPI interface, with registers that say how many steps to make, with specified velocity and acceleration curves.  That would provide very simple interfacing with fewer wires and could allow much tighter servo loops, at the price of putting a microcontroller at each wheel (probably adding $10 to the retail price of the wheels).

Next Page »

The Rubric Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 248 other followers

%d bloggers like this: