Tag Archives: Science Education

Recruiting the Girls.

18485799_1373393066108921_6346993731891607211_n

This post was written by Johnie Lee Fain, a recent graduate of San Rafael High School and the Academy. She is currently planning on studying computer science at Villanova University

 


I spent three years of my high school career in the engineering lab, and at most, there were six other girls beside me.

As a high school senior presented with the challenge of choosing an engineering project to research and produce as the focus of my third year in the Academy I turned to my own experience. I wanted more female students to discover an appreciation for not just STEM studies, but applying it to their own interests, whether that be art, fashion, literature, etc. Based on my opportunity to work with physics, fabrication and design, and computer science, my goal was to reach out to other girls, and facilitate a community of exposure and collaborative thinking for female students on campus and their varying degrees of interests in a STEM education. I then took this inspiration and used programming as my platform.

The graph below shows the enrollment ratio of male to female students From the 2013-14 academic year to 2016-17. 

graph

After initial research of the outstanding gender gap in science based fields, I focused my project development on the San Rafael High School campus specifically. Aside from my own opinions, I sought to learn and understand the experiences of my female peers in STEM as well as those who showed little enthusiasm about the subject. Thus, a discussion group was created to pair girls with little to no experience in STEM, with another eagerly involved student. This transition sought to introduce topics of discussion, and create a space for learning, project development and sharing of peer to peer experiences. Through this I sought to introduce Science, Technology, Math and engineering as an opportunity rather than an unknown.


girls_screening

SRHS Girls at the screening of CODE: Debugging the Gender Gap

There was a larger emphasis on social participation in my project than I had expected initially. I found myself talking to administrators, talking to younger students, and researching new ways to encourage young females than focusing on the technical aspects of my project. It is safe to say I underestimated my ability to create a recruiting website from scratch when I was still learning the basics of Computer Science. This deficit in what I thought was my only was to reach out to the community was in fact an example of the very work I was trying to emphasize. That while learning something new, I could share my thoughts, work and progress withe the girls around me.


Outside of San Rafael, I found mentorships and employment opportunities to help guide my project. Under the guidance of Ryan Robinett, a former partner at the software company Digital Foundry, I was able to visualize what I was attempting to accomplish in website design in the “real world.” This exposure not only broadened my understanding of the complexity of computing but as well as its team based nature. I felt somewhat vindicated in my struggle to produce something original when on a day to day basis software engineers are working in groups almost entirely. Additionally, my employment as a coding instructor at Mill Valley Code Club, a program designed to teach elementary through middle school students how to computer program, I was practicing how to explain and teach the vary programming fundamentals I was learning to a younger audience. Certainly solidifying the material I knew, and highlighting what I had yet to understand.


Ending the year I found I had not only exposed myself to programming in a variety of ways but had introduced the importance of collaborative thinking and communication amongst the female students and their envelopment in STEM education. Moving forward, the importance is consistency. Through deliberate action and communication, the next batch of San Rafael High School Engineering Academy graduates have an opportunity to continue to close the gender gap and inspire others.

girls_screening2

SRHS girls meeting the film maker of She Started It

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.

projectile-motion-600

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.  


phymod1

A Hybrid Solution Is Needed: Tychos

Tychos (tychos.org) 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:

cvpm_canvas_6

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:

settings

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.

Graphing

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:

graph

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.”

goals

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: tychos.org. 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 (stemple@srcs.org) or Winston (winston@nitidbit.com). 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

fritzing-preview-pcb

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.

pcb-milling-opener

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.

2323-00

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.

img_3283

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.

Our Custom Designed Bridge Tester

Our Goal – Make A Better Bridge Crusher!

This year Bob and I decided to upgrade our bridge project. We wanted to create an improved device for measuring the load on the model bridges created by the students. Specifically, we wanted to design a way for the students to collect meaningful performance data.

The problem with our old method (filling a bucket with sand until the bridge catastrophically failed) was that it didn’t allow for the students to collect evidence about where and why the bridge failed. In many cases, the bridge actually experienced a significant failure, but because the bridge collapsed around the loading plate, the loading plate actually acted as a support for the bridge.

We had seen other “bridge testers” from vendors (http://www.pitsco.com/Structures_Testing_Instrumenthttp://kelvin.com/kelvin-bridge-material-tester-w-cpad/http://www.vernier.com/products/sensors/vsmt/) but we had the idea that perhaps we could create one that might be better, or at least it might be fun to try. In this post, we are going to share with you what we created and why we think it actually turned out really well, but we also point out some room for improvement.

The Frame

The frame of the entire device is really based on the Vernier Structures and Materials Tester. We thought this frame was probably the best, and we wanted to make our tester from extruded aluminum tubing as well. We went about designing the bridge tester in our favorite CAD program, Fusion360 by Autodesk. We sent our CAD file to the company 8020 and they precut all our t-slotted aluminum frame members to size. This was awesome because it made assembly super easy and it saved us on shipping too! Our experience with this company was amazing – they were super helpful and even gave us some really helpful advice. If you are thinking about making anything requiring t-slotted aluminum, definitely order from them.

The Load Sensors

We wanted a a bridge tester that actually gave us data that allowed us to figure out how and why the student bridges failed. That meant that we needed more data and we needed data that could be connected to the design and fabrication of the bridge. We noticed that all the vendors’ designs had only one load sensor, and some also had a way to detect overall deflection. We suspected that we could get better data if we had four independent load sensors – one for each abutment where the bridges were supported. The four sensors would (theoretically) give the students a way to analyze how the load was being distributed, and thus tell us something about the torsional behavior of the bridge.

Sparkfun load sensor

Sparkfun load sensor

I set out to learn a bit about load sensors and I came across a fantastic tutorial at Sparkfun (https://learn.sparkfun.com/tutorials/getting-started-with-load-cells). We ordered four load sensors (see picture above) from Sparkfun. Our design (shown below) has the four load sensors  fitted with 3D printed “shoes” as the bridge abutments.

IMG_3048

The four load cells.

IMG_3044

Two load cells with abutments.

The sensors are mounted on custom fabricated aluminum plates that can be moved laterally to accommodate slightly different bridge widths. The load sensors had to be connected to load amplifiers that were then connected to an Arduino (more on that below). The load sensors were mounted to the frame of the bridge tester on custom laser cut plates:

IMG_3043

Load cell amplifiers for two load cells.

The load amplifiers have to be used with the load sensors in order to amplify the signal so that the Arduino can read the data correctly.

The Loading Mechanism

Bob designed and fabricated the loading mechanism that was based on many of the designs we had seen online. It consists of a block that is free to move vertically up or down a threaded rod which is then connected to a spoked wheel.

IMG_3047

Loading wheel.

When the wheel is turned, the block moves up or down the threaded rod. This bar is connected to a loading plate via a metal cable that hooks into the loading plate and the block:

IMG_3053

Load plate from below – revealing loading wire attachment.

IMG_3052

Loading wire attached to threaded block.

The loading plate is placed on the loading plane of the bridge (the “roadway”), and then the bridge is loaded by spinning the wheel, which lowers the block, which pulls the bridge downwards:

IMG_3050

Loading plate on bridge.

Collecting The Data: The Software

 The software responsible for collecting the data is made up of two programs – one that runs on the Arduino micro-controller that is connected to the load sensors, and the other is a Processing sketch that runs on a computer/laptop connected to the Arduino via USB. The code is pretty simple, and it was mostly written using code from other sources and then modified for our specific purposes.

The Arduino code just collects the data from the four load sensors and then sends the data serially as a comma delimited package. The Processing code reads the serial port and then essentially dumps the data into a csv file. It does have some flourishes like a graphical display of the individual sensor loads as well as a display of the total load and whether or not the bridge has met the minimum load requirement set in the project descriptor.

You can view and download all the code here on GitHub.

The Performance Report

When the data is displayed in a graphing program, it looks like this:

Sample bridge data

Sample bridge data

You can see that the four sensors do not read equal values, and that the bridge begins distributing the load unevenly. The blue and orange lines show that these two load sensors were equally loading and were taking on a larger load than the green and red values from the other two load sensors. Later inspection of the bridge showed that this bridge failed at the load sensors that were recording a higher load value. Also, these sensors were located diagonally from one another, and once again showed that the bridge was being twisted.

You can also see that around 80 seconds (the 800 data sample) that the bridge experienced a sudden decrease in load – this was the point of failure. The data clearly shows a point at which the bridge failed and thus gives us a clear metric for performance.

The student teams were each given the results and were asked to answer these questions:

  1. What was the maximum load that your bridge sustained before failure?
  2. Calculate the load to weight ratio of your bridge.
  3. What were the individual maximum force values on each load sensor before failure?
  4. Identify on your bridge where the bridge failed. Take a picture of this point of failure and note its location.
  5. Based on the load data for the four sensors, describe why your bridge may have failed.
  6. What could you have done to increase the performance of your bridge?

The data really allowed for some rich analysis and the students were able to make some really informed critiques of their design and fabrication quality. We have been very happy with the results!

Future Improvements

For version 2.0 we hope to add these improvements:

  • Add the ability to measure deflection. We think that this might be done by measuring the angular displacement of the loading wheel, but we aren’t sure just yet.
  • Some way for the software to detect a failure – perhaps a way to detect a significant decrease in the load data. It would have to allow for some downward movement of the load data because there is some settling and deforming that can occur that might not be catastrophic.
  • It would be nice to clean up the code – especially the Processing code. I’d like to add some fancy GUI elements too so that it is a bit more attractive.

If you would like to build your own advanced bridge tester for your classroom, we can send you all our CAD files, software files and even answer questions. Its not easy to build, but its fun, and we spent about $350 dollars on this project as opposed to the $1000 to $1300 that the vendors are selling theirs for.

A Modernized Bridge Design Contest

IMG_0283

Modernizing An Old Classic

We have just completed the second project in the Academy for the 2014-15 school year. It was a huge success! This project takes a classic physics project and “upgrades” it by incorporating modern engineering design technology and fabrication techniques.

We started with a great project that is now available online through Engineering Encounters. This was a project that was originally published by Stephen J. Ressler of the United States Military Academy. It is a rigorous approach to designing and building bridges from file folders:

https://bridgecontest.org/resources/file-folder-bridges/

Its a great project with an incredible set of resources, background information, and step by step instructions. Unlike less rigorous and involved bridge design projects (using toothpicks for example), this project has the students building compression members (beams) and tension members (cords) and gussets to better model real world designs and to give the students the opportunity to learn and make decisions about which members to use in different parts of their own designs.

The only issue that we had with this project is that it requires the rather tedious process of having students trace out the unfolded beam designs onto file folder material and then use scissors and  blades to cut out each beam and cord. But we have a laser cutter! There had to be a way to incorporate both 3D CAD design and our laser cutter in order to modernize this process. We also knew that Autodesk Inventor had some really amazing tools for analyzing design structures.

From Sheet Metal To Manila Folders

Autodesk Inventor has an amazing set of tools for designing sheet metal parts. Using these tools, an engineer can construct 3D models made of folded metal parts made from just about any thickness of metal stock. Once you have designed the folded metal part, Inventor will create a flat pattern design for you that you could then send to a CNC plasma cutter to cut from sheet metal stock. You would then fold the part up manually and you would have your folded part.

Inventor gives you the ability to custom define the thickness of your stock, and some of the parameters around how it can be bent. We defined our stock to be as thick as manila folder paper. The next step is a bit tricky, but with the help of a great video I came across from Rob Cohee, we were able to define custom folded paper beam stock that the students could then use to build out their frames. Once again, Inventor has an amazing set of tools for defining structural frames (called The Frame Generator) that can then be populated with any kind of structural beam. You can also define your own structural beams that can be used to populate your frame.

I have included a video below that we use with the students to help guide them through this process:

Using the frame generator tool in Inventor also allows the student to miter and trim the beam members, which allows the students to focus on design rather than getting lost in the time consuming process of calculating the cut angles. The following video shows you how this can be done:

Once the students had designed the bridges, it was time to prepare the flat patterns and have the laser cutter do the work of cutting them out.

Fold, Glue, Repeat. (Some Assembly Required)

IMG_0353

The students prepare their flat pattern cut-outs for the laser cutter and then you let the laser “rip”! Its awesome to sit back and watch this machine cut. I never get sick of watching it! Having the students do this would take SO much longer, the cut parts would be less accurate, and as all CTE teachers know, one of the most dangerous tools in the shop is an Exacto blade.

IMG_0355

Some might argue that the “manual” process of cutting all these beams out by hand is “good for the students”, but we feel that saving time here allows us to use that time in other areas, such as virtual testing.  Before the students get to build their design, we ask them to use Inventor’s frame analysis tools to help them analyze potential weaknesses in their designs. The following video shows just how amazing this tool is:

Once the students have done their analysis and cut their construction members, its time for folding and gluing, and folding, and gluing, and … At this point our project does not differ from the Engineering Encounters project. The students use a sheet of paper (actually two 11 x 17 sheets) with an elevation view (printed from Inventor as a CAD drawing) glued to a board as a guide for assembling the beams, cords and gussets:

IMG_0351

IMG_0362

This process goes relatively quickly as the students have done all the prep work to make sure that the pieces all fit together. Once again, this really demonstrates how modern technology can allow the students to focus their attention on design.

To Break Or Not To Break

Once the bridges are assembled, its time to test them out. The performance metrics for the contest are not actually based on the strongest bridge but rather a more realistic approach. We have attached a monetary value to each beam, gusset and cord. The bridges are then tested to a set value – the required load. The bridge that holds that load and is “manufactured” least amount of money is then given the highest marks.

Once the bridge has been tested at the required load, we then give the students the choice to see just how much the bridges can hold before catastrophic failure. Most students (encouraged by both peers and staff!) decide to take their bridge to the limit.

Its always a fun way to end the project!

Simulating Planetary Motion (Using Code!)

Simulating Newton’s Law of Universal Law of Gravity

Interactive simulations (like those created by the University of Colorado – PhET) can be really nice for impressing students, and giving them a way to explore the dynamics of a simulation. If incorporated into a lesson well, they can add to the active learning process. The question that I always struggle with though is “are the students learning how the simulation works, or are they learning how nature works?”

I have a nagging feeling that the students would possibly get more out of being able to see the simulation source code, specifically the rules of behavior of the simulation, and then through “tweaking” the code, see how those rules govern behavior. I would like to develop curriculum that would allow my students more opportunities to explore the code “behind” the simulations. This presents a few challenges that have been identified by other great physics educators, and if you are thinking about doing the same thing – I would suggest reviewing their insights. I include a quote from Ruth Chabay’s brief, but very interesting article on this topic:

To integrate computation, especially programming, into an introductory course, it is necessary to minimize the amount of non-physics related material that must be taught. To do so it is necessary to teach a minimal subset of programming constructs; employ an environment and language that are easy to learn and use; ensure that program constructs match key physics constructs; provide a structured set of scaffolded activities that introduce students to programming in the con- text of solving physics problems

This was my first attempt at doing just this, and I had some success and realized that I have some work to do.

Which Code?

A popular programming language in the Physics Modeling community is VPython. I have chosen to use a different language to use called Processing. There are reasons I chose this language, but I am sure there are reasons one would choose VPython (or other languages). At this point, I have not had the opportunity to work with VPython, so this post will not attempt to compare Processing to other languages. Perhaps I will do so in the future…

Here are some general reasons why I like Processing:

  1. It’s free and open source.
  2. Because its built on a visual programming interface, its really easy for the students to create visual content on the screen, and it is very easy to create visual animations due to the embedded “draw” loop.
  3. The official website has great examples and tutorials. It is full of great code samples and quick tutorials. You can loose yourself for hours (or days!) just having fun exploring the examples and tutorials.
  4. The IDE is simple and very similar to the Arduino IDE, so if you plan on doing any Arduino programming, the similarity is nice for the students.
  5. There is a nice vector library for doing vector operations (.add, .mult, .norm, .dot, etc.)
  6. Its object oriented so that you can have the added benefit of teaching important programming concepts – though this might be why some people might not like it.

The Simulation

The simulation that the students were introduced to was a simulation that modeled Newton’s Law of Universal Gravitation. The students were given some instructions on the basic structure of the program, and I made sure that there was some guiding comments embedded in the code. This program was inspired/adapted from a similar program created by Daniel Shiffman who has also written an amazing book on simulating nature through code called Nature of Code.

The program defines two classes. First, there is the parent class called Particle. This class defines some basic attributes like location, velocity and acceleration as well as mass. It also has some basic functions that allow it to move and allow it to respond to a force. The second class is the child class called Planet. It can do everything that a Particle can (because it inherits from the Particle class), but it can also exert an attractive force on other Planets.  Here is the code below:

/* A parent class for all moving particles
class Particle {
  PVector location;
  PVector velocity;
  PVector acceleration;
  float mass;

  Particle(float x, float y, float m) {
    mass = m;
    location = new PVector(x, y);
    velocity = new PVector(0, 0);
    acceleration = new PVector(0, 0);
  }
  
  void applyForce(PVector force) {
    // Newton’s second law at its simplest.
    PVector f = PVector.div(force,mass);
    acceleration.add(f);
  }

  void move() {
    velocity.add(acceleration);
    location.add(velocity);
    acceleration.mult(0);
  }
}

/** 
 This class defines an object that behaves like a planet.
 Planet objects extend Mover objects, so they can move. They
 also can attract other planet objects.
 **/
   
class Planet extends Particle {

  float size;
  float G = 1;

  // To create a planet, you need to supply coordinates, mass, and size
  Planet(float x, float y, float m, float s) {
    super(x, y, m);
    size = s;
  }

  // This function allows a planet to exert an attractive force on another planet.
  PVector attract(Planet p) {

    // We first have to figure out the direction of the force
    // This creates a unit vector for the direction
    PVector force = PVector.sub(this.location, p.location);
    float distance = force.mag();
    distance = constrain(distance,size + p.size,500);
    force.normalize();

    // This is where we use Newton's Law of Universal Gravitation!
    // The stength of the attraction force is proportional to the
    // product of the mass of this planet and the mass of the other planet
    // as well as the value of G. It is also inverseley proportional to
    // the distance squared.
    float strength = (G * mass * p.mass) / (distance * distance);
    
    // To get the final force vector, we need to 
    // multiply the unit vector by the scalar strength
    force.mult(strength);

    // Return the force so that it can be applied!
    return force;
  }
  
  // Just displays the planet as a circle (ellipse)
  void display() {
    stroke(255);
    fill(255, 100);
    ellipse(location.x, location.y, size/2, size/2);
  }
  
}


/** 
  This program simulates the gravitational interaction between planet objects
  **/
  
Planet planet1;
Planet planet2;

void setup() {
  background(0);
  size(800,800);
  // Inputs for each planet:
  // (x, y, mass, radius)
  planet1 = new Planet(width/2,height/4,6000,60);
  planet2 = new Planet(width/2,height/1.25,6000,60);
  
  // This is where you can change the initial velocities of the planets.
  planet1.velocity.x = 0;
  planet1.velocity.y = 0;
  planet2.velocity.x = 0;
  planet2.velocity.y = 0;
}

void draw() {
  background(0);
  
  // f1 is a force vector that is created by calling the planet's attract function
  PVector f1 = planet1.attract(planet2); 
  // Now apply that force on the other planet.
  planet2.applyForce(f1);
  // Now deal with the opposite force pair
  PVector f2 = PVector.mult(f1, -1);
  planet1.applyForce(f2);
  
  // Allow the planets to now move.
  planet1.move();
  planet2.move();
  
  // Display the planets
  planet1.display();
  planet2.display();
}

Experimenting With The Code

The students could change the initial values of the planets, such as the starting positions, the masses and radii by changing the input values of these two lines of code:

planet1 = new Planet(width/2,height/4,6000,60);
planet2 = new Planet(width/2,height/1.25,6000,60);

The planets initial velocities could also be modified by changing the values assigned in these four lines of code:

planet1.velocity.x = 0;
planet1.velocity.y = 0;
planet2.velocity.x = 0;
planet2.velocity.y = 0;

The code that actually guides the strength of the gravitational attraction between the two planets is actually very simple. This is the magnitude of the force as defined by Newton’s Law of Universal Gravity in code:

float strength = (G * mass * p.mass) / (distance * distance);

There is some slightly complicated code that controls the direction of the force and how that force is then applied to the planet object’s state of motion, but I didn’t have the time to explain this, which was a bit disappointing (see below).

For The Future

I am currently really interested in incorporating programming into the academy program, but have found myself a bit intimidated by the challenges identified by Ruth Chabay. The most significant challenge is time:

In an already full introductory physics curriculum, there is little or no time to teach major programming skills. Students who are new to programming are also new to the process of debugging; teaching debugging strategies requires even more time…Working on programming activities only once a week in a lab or recitation section may not be adequate to keep knowledge of syntax and program structure fresh in the students’ minds.

I plan on taking some time this summer to see how I could integrate computer programming more significantly into the curriculum without causing the learning of Physics to suffer – that would of course defeat the purpose!

We Have Lift Off!

15414703973_b0258a08ca_h  15846865828_b08d8515cd_h 16033503742_be978fd9ca_h

This is a follow up post to Modeling A Rocket’s Journey – A Synthesis where I described how the students in the first year program were engaged in creating a predictive report for their model rockets. I want to emphasize that these model rockets were not kits. Each rocket was designed using 3D CAD software, and each component was either fabricated from raw material, or was created from material that was not intended for use in model rocketry. The only exception to this is the actual rocket motor.

The next step was to launch the rockets and have the altimeter payload collect altitude data.

Launch Conditions – A Bit Soggy

Unfortunately the week of our scheduled launch happened to be a week of some pretty hefty rains. We rescheduled the launch twice before finally accepting the soggy launch conditions. With umbrellas and rain jackets, we trudged out to the baseball diamond and got to work setting up for the launch. We had some minor difficulties in the wet weather, but eventually had a very successful launch day.

Most of the rockets were able to launch and deploy their valuable payload – the Pnut Altimeter.

15414689283_8197c70584_h

The students seemed very excited to finally see the rockets launch, and to see the successful deployment of the parachutes. Although we all got a little wet and muddy, we had a great time!

The Altimeter Data

The altimeters use a small barometric pressure sensor to collect altitude data (the altimeters also contain a small temperature sensor and voltage sensor). The altitude is recorded in feet every .05 seconds. Here is an example of one rocket’s recorded flight data:

altitude_vs_time

https://plot.ly/~stemples/9

The students were then asked to use the data to create a comparative analysis report. I will detail how the assignment was set up and also discuss how the students performed on this assignment. That will be for another post.

I want to also thank Mr. Kainz for his amazing photos that are displayed here.