Category Archives: Computer Science

Helping Students Create Their Own Mini Universes

For the past year, I have been helping a small software development team, headed up by my friend Winston Wolff, in the creation of a web based physics simulation tool. In this blog post, I am going to describe:

  • Why we started this effort,
  • What we hope to achieve,
  • How far we have currently progressed towards our goals,
  • And invite you to try it out.

Simulations Can Be Helpful…

Many Physics teachers use computer simulations as a tool to help students learn physics. With a click of the mouse and a few keystrokes, students can quickly change the inputs to the simulation, producing different simulated behaviors of the system. This allows for quick exploration of the relationship between certain “physical” inputs and the governing dynamics of the system. Often, these explorations would be impossible to set up in the lab, or might take significant time and effort.


A great PHET simulation of projectile motion

…But They Have Limitations.

Although these tools can be used with a high degree of success in the classroom, the students are interacting with a virtual universe created by another human. The rules of behavior and the underlying quantitative relationships have been defined by someone else who has already done the difficult work to model the physical universe. These relationships can be inferred and they can be explored by the student, but ultimately, they are hidden behind an impenetrable wall of software code. There is also a certain faith that the student must have in the simulation – there must exist an acceptance that the simulation creators did their job correctly.

Students Coding Their Own Simulations is Awesome… 

Some highly regarded physics educators have introduced the practice of teaching computer programming in the physics classroom. The advantage of engaging students directly in the construction of simulations, according to Ruth Chabay and Bruce Sherwood

is that there are no “black boxes”: students write all of the computational statements to model the physical system and to visualize the abstract quantities.”

Additionally, they argue that having students gain some experience and exposure to computational modeling

in the form of programming, even at the introductory level, can be an important component of a general education for living in today’s world.

Giving students the opportunity to write their own simulations gives them the ability to engage in computational physics directly and to give them vital experience in one of the aspects of being a scientist – namely writing some code.

… But There Are Challenges For Teaching Coding.

Although there are great reasons for integrating computer science with Physics, and therefore developing students’ understanding and experience with computational Physics, there are some significant challenges for the teacher.

Teaching students to code their own physics simulations is not trivial. It requires significant instructional time, even given the fact that there are some amazing tools and frameworks for graphics programming (VPython, Processing). Chabay warns that time spent on teaching computer science principles and practices needs to be assessed against the time lost teaching and learning physics.

Due to the complexity and in many cases, the lack of exposure to computer science and “coding”, students can become lost in the syntax and specific computer science discourse, thus leading to confusion about the actual physics principles.  


A Hybrid Solution Is Needed: Tychos

Tychos ( attempts to address the strengths presented by simulations and combine it with the value of computational modeling. It is a simulation tool that has been built to address the lack of transparency inherent in pre-constructed simulations while also simplifying and accelerating the acquisition of the skills needed to “code” the underlying physics.

We have never seen Tychos as a replacement for laboratory experiments. Quite the opposite, we see this as a way to enhance the laboratory experience. It gives students the ability to quickly define a hypothesis in code for anticipated behavior of a real experiment. Students can then run the real experiment and see if the simulation behavior that they defined matches or does not match the behavior defined by nature.

No Black Boxes

The rules of the simulation are created and coded by the student. At its base, Tychos is really just a “drawing” and computational tool. There are no “virtual physics” built into the environment. Those rules must be defined and implemented by the student.

For example, if a student wants to simulate a particle moving in space with a constant velocity, they simply need to define the particle by using one of the few built in functions to place the particle at a position, set its visible size, and then optionally display with a given color, in this case the color red:

p = Particle([0,0], 10, "red")

The “particle” is really just a graphic “dot” that appears on the screen. The simulator has no concept of movement, or mass, or energy, etc. The student must build in those rules. So for example, the student defines a numerical matrix to represent the particle’s velocity:

p = Particle([0,0], 10, "red")
p.vel = [10, 0]

Then the student can use that variable to define how the particle will move in time. This is done by utilizing one of the few built in physical variables in the simulation software – “dt” which represents delta time:

p = Particle([0,0], 10, "red")
p.vel = [10, 0]
p.pos = p.pos + p.vel*dt

With these three lines of code, a student can simulate a particle moving in space with a constant velocity. The student makes that happen and therefore the mechanics of the behavior are not hidden but rather fully exposed for the student to define.

Built In Physics Analytical Tools

We have tried to create an environment where students have access to a suite of analytical tools that either do not require any coding, or very little.

Visual Representations

As we develop Tychos, we are constantly looking at how we can make the tool easier to use for students. A few features that we have included are important visual representations that are commonly used to help represent motion. For example, we have made it very simple for students to see motion maps of their particles by simply clicking a button. We have also made it very easy to display vector arrows for any vector quantity, and to attach those vectors to a given particle:


This allows students to quickly assess the behavior of the simulation without needing to spend time learning how to implement complex tools.

Easily Adjust Simulation Parameters

We have also tried to remove any coding that isn’t specifically targeted at modeling physics. For example, Tychos has a simple set of simulation parameters that can be changed with a few simple controls:


The above panel shows that a student can change the frame rate, the motion map strobe rate, set a simulation stop time, and change the extents of the viewing window – all without writing a line of code.

Coding of the GUI, rendering graphics, running the animation, etc are taken care of so there is less to program. The programs are much shorter and the code is more focused on the physics concepts, e.g calculating how force and momentum affect the position of a particle. There is no “boiler plate” code that needs to be used to get started which we have found to be cumbersome and confusing for students. Students spend less time learning programming and more time learning physics.


One of the great features that we are excited about and that I have found incredibly useful in class is the built in graphing tools in Tychos. With two simple lines of code, a student can graph any variables on a simple to read graph.

This allows for the student to graph the position, velocity,  and acceleration of a particle as a function of time (called motion graphs) but they can also graph energy, momentum, force, or any virtual quantity defined in the simulation code.

In the following example, the student has defined the kinetic energy of a particle and then has defined and displayed a graph for how the energy is changing with respect to time:

KEgraph = Graph("KE vs Time")
KE = 0.5*p.mass*p.vel*p.vel
KEgraph.plot(t, KE)

The graph then looks like this:


This graph appears just under the simulation window, and the student can then easily connect the behavior of the simulated particle to the behavior of the graph.

Integrated Formative Assessment:

Tychos has been built around the concept of a learning system. From the ground up, we have built in features that are designed to engage the student in the learning process. Tychos includes fast feedback in the form of instructor defined goals which are checked by the system such as “Your simulation should calculate position of particle at time 3 seconds.”


These goals keep students on track and allows for students to self assess. We have also noticed how these goals make the learning exciting. Students have expressed how much they enjoy watching the goals turn green as they accomplish them.

Teachers can also use the Goals as a quick and easy way to assess the learning progress of the entire class, and then focus on individuals that are having trouble. The teacher has the ability to peer into the individual student’s work and we are even building into the application the ability to see a “code history” of each student so that the teacher can track down the origin of a learning challenge and then direct the student to a specific solution.

Our Roadmap

We think we are off to a great start with this app, but we also realize that there are a number of great potential features that we hope to add. This is a rough outline of our future goals:

Tracking Student Progress

Soon the tool will show each student’s progress in realtime to the instructor so the instructor can maximize their time helping the students who need it. The tool will also allow instructors to see the work each student does, e.g. each attempt the student has made, the difference from the last attempt, and its outcome to help the instructor quickly deduce where the student’s thinking is and what is blocking her. Additionally, the instructor will be able to automatically export assessment data based on instructor’s defined criteria.

Custom Defined Classes

We want to give the students the ability to define reusable components so that we can further reduce the amount of code that is needed to create a simulation. We are working on some strategies to build that into Tychos.

Data Export/Import

To extend the connection between Tychos experiments and in class laboratory experiments, we intend to add the ability to export and import data to and from other data collection software like Logger Pro. This will allow more precise comparisons between simulated behavior and measured behavior from motion detectors or force sensors.

Looking For Feedback

We are continuously looking for ways to improve our application, and we have no shortage of ideas. Our next challenge is finding the time and resources to make those future enhancements possible, but we are eager to have other Physics teachers try this tool out and let us know what else we should do to make this a better learning and teaching experience.

If you are interested in trying this application out, please visit our website: If you would like to give us feedback, or have questions, please feel free to post a comment on this blog post or contact me ( or Winston ( We would love to hear from you!


The Great (Mini) Robot Race

Robotics – The Synthesis Project

The final project of the two year academy program requires that the students design, fabricate, program and test an autonomous robot. We have been doing this project since the inception of the program, but this year we have made some significant improvements on the project. In this post I will explain the project, and highlight those improvements.

This project is an extremely challenging task that requires successfully completing several “sub-projects”. We tell the students at the beginning of the school year, that this project is more difficult than any of the other projects – by a long shot!

“If you haven’t done everything, then you haven’t done a thing.” – Red Whittaker

We completely changed our robot competition parameters this year. In previous years we had the students design sumo wrestling battle bots. Although this was a fun project, we started to notice that some robots performed really well without really having to “think”. These robots generally lumbered around the ring, sometimes without even actually “seeing” their opponents. Through pure luck they just managed to push their lighter opponents out of the ring. We decided that we needed to change the project in order to force teams to be smarter and we also wanted to get away from a robot competition that seemed to focus on aggressive battle.

Ironically, I suppose, our robot project changes were inspired by the classic Nova film that documented the DARPA challenge known as the Great Robot Race. In this race, the autonomous vehicles raced through the Mohave dessert on a course that was revealed to the competitors only hours before the beginning of the race.

Bob set about building an impressive “maze” for the robots to navigate. The robots had to make their way through a series of 90 degree turns defined by a series of connecting corridors with vertical walls about 20 cm tall. The robots were then given two attempts to make it through the course as fast as they could.

The Brains and Braun

When we first started this project about twelve years ago, we first used a Java based board that we liked, but it was really expensive and we didn’t really need much of the hardware and software features that it offered. About eight years ago, the Arduino board was taking the Maker community by storm and we decided to hop on the Arduino bandwagon, and we have been very happy ever since. The simplicity, online community, the plethora of code examples and tutorials as well as the price have been key points in why we have decided to keep using the Arduino. This year we decided to incorporate DC motors from Sparkfun and Adafruit’s motor shield. The combination allowed the students more flexibility regarding drive train design, and also allowed for some interesting discussions around the advantages and disadvantages of servos vs dc motors. Our only complaint with the shield would be that it would be nice to have the headers pre soldered!

Designing The Circuitry


One of the major additions to the project was to require that students design and fabricate the circuitry for their robots. We did this by introducing two new skills to the project. Students had to learn how to use a printed circuit board (PCB) design software known as Fritzing, and then they had to learn how to fabricate their PCB boards using a CNC mill.

There are a number of amazing PCB design tools out there – and many are free! They all have their strengths and weaknesses. Here is what we found out as we did our research to find the right tool.

Autodesk’s Circuits is great because its web based, super easy to use and has an amazing feature where you can actually simulate the circuit. You can add a virtual voltmeter of ammeter to your virtual circuit and then with a push of a button, you can get virtual readings on the meters. I found this tool to be amazing for teaching circuitry and I allowed the students to use it as a “key” for their worksheets. It also has the ability to simulate an Arduino too! You can add an Arduino to your project, connect up LED’s, servos, etc. and actually see them light up or rotate as you change the code. It is a bit limited in that it doesn’t support most added libraries, but it is still amazing. We eventually decided not to use it for PCB design because it is unfortunately a bit clunky and doesn’t allow for much customization of the board.

Eagle is of course one of the most advanced and feature rich PCB design tools out there. It is also very complicated. IT of course offers the largest toolset, complete control of the design process and the free version is as close to a professional tool as one could hope for. The problem is that all these features come at a price – complexity. If we had an entire year to spend on this project, I might have decided to go with this tool, but we needed something that the students could learn quickly and weren’t going to get frustrated with…

Fritzing is a free, open source “beta” software that is very similar in look and feel to Autodesk’s Circuits – in fact I think Autodesk’s product must have been inspired by Fritzing? Although Fritzing lacks the amazing simulation tools that Autodesk Circuits has, it does offer a much better PCB design environment. The options that are available for editing the component foot prints, the PCB attributes, etc. make it really nice to work without making the tool too complex. This is the tool we decided to teach and use in class, and the students liked it.


Fabricating The Circuitry

Back in the fall we decided to invest in a small CNC mill produced by a local company out of San Francisco named Other Machine Co. This machine, called the OtherMill has been an amazing addition to the lab. With this machine, we have been able to teach the students how to fabricate their own PCB’s. The OtherMill is not just for PCB fabrication, in fact we have used it to mill small aluminum parts as well.


This micro CNC desktop mill is super easy to setup, really easy to use and plays really nicely with Fusion 360 – our 3D CAD and CAM software. I was incredibly surprised and pleased by how easy it is to learn the operating software – known as OtherPlan. The company has a great support website full of great tutorials, and we were able to teach all the students how to use the machine in just a few days.

The PCB files generated by Fritzing (we exported them as Gerber files) worked flawlessly with the OtherMill, and within a very short period of time, all the students had designed and fabricated single sided PCB boards for their robots.


The Final Results

As with any major changes to a project, there are lessons to be learned. We realized that the task was rather complicated and many of the students did not make it as far through the course as they had hoped. It was clear however that this competition proved more interesting from the perspective of getting students to see the importance of software design. Not only did we see very different software strategies, but the variance in hardware design was surprising. They really had to think about how the hardware and software had to work together, and they had to think about optimization. This was a clear advantage of this competition over the previous year’s competitions. Students spent far more time trying to figure out how they were going to shave time off their attempts, and how they were going to adjust software and hardware to better navigate the course. From our perspective, the changes to the project proved to be fantastic, and we are looking forward to improving on the project design for this year. Some of the things that we are going to do this year is introduce some different sensors for the students (like “feelers”) and also give them a price list and budget so that they have more hardware choices.