Computational Deployment: Simulating A Rocket

Posted on December 22, 2018 by Steve Temple

The model rocket project has long been a favorite at the Academy. For the past fifteen years, students have designed, fabricated and then launched model rockets as the first project of the program. Over the years, I have tweaked the project several times, each time finding new ways to introduce authentic analysis in the process.

This year I have taken a deep dive into computational modeling, and as part of the rocket project, students were asked to create a simulation of their rocket prior to launch. In this post I will discuss how I did this, and how it turned out.

Simulating The Momentum Principle:

Prior to getting started on this, students investigated the causal relationship between forces and changes in motion. Using force sensors, carts, weights and elastic cords of different lengths, students began building a qualitative and quantitative model relating the momentum of a particle to the forces acting on the particle.

In previous years, I waited to introduce momentum until after a significant amount of time was spent on forces, balanced and unbalanced. This year I decided to go directly to momentum. This is a bit of a break from the established modeling instruction sequence, but I think its a good alternative that is also suggested by the great textbook Matter and Interactions. The momentum principle can easily be modeled computationally and I think the students are able to grasp it conceptually.

I have included a link to a Google Doc that is the introductory activity that I created. My approach here, as it has been with this entire unit is to give the students guided questions that allow the students to discover and investigate the code required to simulate the momentum principle. This is my first attempt, and I am sure it will undergo many revisions:

Simulating The Momentum Principle

Introducing Conditional Behavior

One of the really great things about building a simulation of a rocket has three distinct phases of its trajectory – the thrust phase, the cruise phase and the descent phase. This gives the students three different phenomena to study and simulate: positive acceleration when two unbalanced forces are acting on the rocket during the thrust phase, free fall when the fuel runs out, and then constant velocity when the parachute has been deployed.

In order to simulate this, students needed a way to change the forces acting on the rocket at different time intervals. This is done using a conditional statement:

If This Then That

Conditional statements are very easy to create in Tychos – but they work a bit differently from other programming interfaces. Here is an example:

# The thrust force - F (thrust, rocket, fuel)
Ftrf = if (t < 1.8, [0, 6], [0, 0])

In this code snippet, a force is given a different value based on a condition, in this case whether the time in the simulation is less than 1.8 seconds. If it is, then the force is given a positive 6 value in the Y direction, and if the time is greater than 1.8 seconds, then the force becomes zero.

This allows the students to simulate the thrust phase of the rocket by having the thrust force disappear once the fuel has run out. We conducted tests on Estes C6-5 rocket engines in order to establish the time value. You can read more about how we did this here.

The students did the same thing to figure out when the parachute should deploy. Again this was established based on information from Estes as well as our own tests.

Comparing Simulation Data to Real Data

The students could analyze the simulated rocket behavior by using the graphing tools in Tychos. The students graphed the vertical velocity as well as the vertical position of their simulated rockets. Here is an example of what those graphs look like:

The last step of the process was for the students to compare their simulated data to the real data that was captured by the altimeter that we use in the rocket’s payload. Below are two images of the graphs of the data they retrieved from the rocket’s altimeter:

velocity data from altimeter – imported into LoggerPro

altitude data from altimeter – imported into LoggerPro

The shapes of the graphs from the simulated data and the real data are very similar! That was certainly exciting to see that the simulations were at least giving results that qualitatively matched the real behavior of the rockets.

Two factors that certainly created significant discrepancies between the real rockets and the simulated rockets was the existence of air resistance on the real rocket, and the fact that the real rockets didn’t always go perfectly straight up! We plan on modifying the simulations, but that will have to wait for a future post.

The Great (Mini) Robot Race

Posted on September 6, 2016 by Steve Temple

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.

Our Custom Designed Bridge Tester

Posted on April 11, 2016 by Steve Temple

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_Instrument, http://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

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.

The four load cells.

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:

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.

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:

Load plate from below – revealing loading wire attachment.

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:

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

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:

What was the maximum load that your bridge sustained before failure?
Calculate the load to weight ratio of your bridge.
What were the individual maximum force values on each load sensor before failure?
Identify on your bridge where the bridge failed. Take a picture of this point of failure and note its location.
Based on the load data for the four sensors, describe why your bridge may have failed.
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.

Testing Motors For The Solar Dragster Race

Posted on November 27, 2014 by Steve Temple

Torque/Speed Curves

In this post I’m going to describe our attempt to measure the power curve for the DC motors used in the Solar Dragster race this year. I’m going to be honest, our efforts weren’t really that successful, but I can at least say that I learned some things that might help for next year, and I think the students were able to do some authentic device testing – a part of being an engineer.

Last year I was a bit concerned that the DC motors that we were using in the Solar Dragster Race were not actually outputting the same power. I wanted to devise a way to measure the motor power, and then have each team do their own analysis. I wanted the students to do this without understanding the electrical power parameters involved because we were at this point only looking at motors as being a black box that gets energy from a source and transfers that energy into a rotational device – i.e. an axle, then to a gear, then to another axle, and finally to a wheel. I looked into getting a torque sensor, but quickly found out that these cost a fortune!

I came across this interesting website from MIT, which was a nice resource for the theory about DC motor performance. The site does a nice job in explaining torque/speed curves, and how the graph of torque vs angular speed is essentially linear for DC motors. That meant that all the students really needed to do was to measure stall torque and the no load speed of their motors and then we would have the torque/speed curve. The website identifies a device that they custom built for testing motors, and it looks interesting, but I didn’t have time to reverse engineer what they had built and unfortunately the images and videos aren’t clear enough to easily understand how the device works – something perhaps for summer tinkering…

One of the issues with the little DC motors that you buy is that the arbor is really small, and it has no index, so its really hard to attach anything. Generally, you have to go with a friction fitting, and I was worried that doing a stall torque test was going to be difficult. Mr. Holt and I designed and printed out a little lever arm to attach to the motors. This little arm could then be attached to a force meter to measure the stall torque and then also used to help measure the rotational velocity using a Photogate. The final “test-bench” looked like this:

The motors were clamped to a lab stand that was then placed so that the little lever arm would rotate and block the Photogate laser as it spun. This is how the students measured the no load speeds. Then they attached a string to the little hole in the arm, and then attached this to a force meter to get the stall torque. All the motors were tested with essentially the same power source – two AA batteries.

I then had the students share their data using a Google Spreadsheet and I compiled the data – here it is on Plotly:

There is obviously some variability in the motor performance, but its hard to tell if any of the motors give a distinctive advantage over the others because I suspect that the data is not that reliable unfortunately. I do suspect that the angular speed data might be inaccurate due to the fact that we were getting some very differing results from the Photogate. Although we made the sampling rate as rapid as possible, I still am not confident that the Photogate was able to read the blocking of the laser accurately – the motors spin VERY fast (upwards of 5000 RPM’s when not loaded). I’m also not sure if the data then could then be used in any instructive way to help students make design decisions about their dragsters.

Although this may seem like a failure, it did allow the students to identify at least two motors that we knew were malfunctioning, so we were able to swap those out before the competition.

For Next Year

I think at this point I would want to make some changes to this activity. Although it was somewhat helpful in giving the students a direct interaction with data associated with the performance of a DC motor, and how that performance is calculated at the product of the torque and angular velocity, I’m not sure that the activity supplied data that was good enough to then use as an input factor in the competition. For example, I didn’t feel confident about allowing students to use the calculated maximum input power as a scaling factor for their dragster race time.

Perhaps next year, we can find the funds to purchase a high precision, digital torque meter, or find the time and money to build our own “analog” torque/speed meter like the one that MIT designed. All in all, I’d say this activity was partially successful.

Our New Full Spectrum Laser

Posted on August 14, 2014 by Steve Temple

Last week our new Full Spectrum Laser arrived at school. Thanks to the generous donation of a graduating senior’s parents, we were able to purchase the Full Spectrum Pro LF Series 36×24 model with a 90 W laser upgrade and active water chiller. This cutter replaces our eight year old laser that has had some serious problems rendering it essentially useless last year, which really affected one of our major projects.

This new laser arrived in a large wooden box that was a bit intimidating as we knew that we had to figure out how to get the laser out of the box and then into the room next door. We had to cut a hole in the adjoining wall, which actually wasn’t that difficult, but we will need to go back and fill that in!

We are really excited about the new device and look forward to using it on the first project of the year.

Academy of Engineering and Technology at San Rafael High School

A project-based approach to science and technical education, where students actively learn through exploration and investigation.

Tag Archives: Making