Water Bottle Rocketry

We started the school year in Principles of Technology with a bang – more like a blast!

The first project, right out of the gates, was soda-bottle water rockets. This was the introductory project for the course and for Unit 1 – Motion.

The class was broken into self-selected teams of 1 to 3. The class was given a complete 2-liter soda bottle and access to random materials from around the classroom. The teams were given 3 90-minute class sessions to brainstorm and complete their rocket designs.

Upon completion of the designs and following the launches, teams completed force diagrams and a post-launch analysis explaining why their rockets performed the way they did.

Here are the various rockets on the morning of the launches…

Driving Finches

My Robotics class was busy for the past few days working in SNAP! to program the Finches to perform various tasks. We started off easy with some pre-programmed sequential instructions like the following:

screen-shot-2016-09-28-at-7-07-15-pm

We then quickly moved up to more interactive non-linear / non-sequential programming which allowed us to create basic driving functionality. Here were the fruits of their labors:

The students seemed to have fun working with the Finches and it gave them the flexibility to focus solely on the automation programming without having to also worry about the engineering design.

Special thanks to Birdbrain Technologies for loaning us the Finches this year for the students to work with!

Easy as Pi

The basic LEGO Mindstorm EV3 truck we are using in this example contains two main drive tires and two smaller “bumper” tires. The balance of the weight is carried on a skid on the back-center of the robot. Each of the main drive tires are driven by a large motor. The task is to pre-program a robot to drive along the border of a 5 foot by 3 foot rectangle.

The main drive tires are the only one that we are interested in to solve this problem. First, we need to know the diameter of each tire. In this case, the truck is using 68.8mm diameter tires. We know the circumference of a circle is calculated by multiplying Pi (π) times the diameter or multiplying Pi (π) times double the radius.

C = πd or C = π(2r)

So, with a diameter 68.8mm, these tires have an approximate circumference of 216.14157mm. This means that for every full rotation of the tire, the robot moves 216.14157mm.

Now, let’s look at the length of our track. It is two 5-foot lengths and two 3-foot lengths. The converts to two 60-inch lengths and two 36-inch lengths. There are 25.4mm in 1 inch. As such, our track consists of two 1,524mm lengths and two 762mm lengths.

Unfortunately, we don’t luck out with our circumference evenly dividing into either of our lengths. This means that to stop at the exact length, the tire will not end at a complete rotation. We must calculate how many complete rotations and then how much of a fractional rotation would be needed for each length.

Let’s start with the 5-foot lengths. Remember, they are 1,524mm. Each complete tire rotation is 216.14157mm. So, we need to do some division:

1,524 ÷ 216.14157 = 7r11.00901

In common English, this means that to travel 1,524mm the wheel must rotate 7 complete times and then an additional 11.00901mm. The problem is how do we tell the computer to accomplish this task?

Option 1 – Fractional Rotations

In LEGO Mindstorm LabView, we can instruct the motor to turn a set number of rotations. In this case, we need to return to our division problem and solve for a floating decimal remainder

1,524 ÷ 216.14157 = 7.05093

This means that the motor will need to rotate 7.05093 times. If we double-check this, we multiply our answer (total number of rotations) by the circumference (distance traveled by each rotation) and should get our total distance.

7.05093 X 216.14157 = 1,523.99908mm

As we are working with approximations of π, a drift of 0.00091mm is sufficiently close.

Option 2 – Degree Rotations

In LEGO Mindstorm LabView, we can also instruct the motor to turn a set number of degrees. We know from earlier that we must perform a minimum of 7 complete rotations and then a fractional rotation.

To perform this calculation, we first need to know how much distance is traveled by a single degree of rotation. For this, we do the following:

216.14157mm ÷ 360° = 0.60039mm/1°

For every degree of rotation, the wheel will travel approximately 0.60039mm. So, to determine how many degrees are needed to travel 1,524mm, we divide that distance by the distance of 1 degree of rotation.

1,524mm ÷ 0.60039mm = 2,538.35007°

This means that to travel 1,524mm, the wheel needs to rotate 2,538.35007°. We know that this answer makes logical sense since we know from earlier that the wheel must complete just over 7 full rotations. There are 360° in a single rotation and 2,520° in 7 full rotations. This leaves 18.35007° to go.

Let’s double-check this. We calculated that a single degree of rotation produced 0.60039mm of travel. So, let’s see how much travel we get with 2,538.35007° of rotation.

0.60039mm X 2,538.35007° = 1,523.99999mm

As we are working with approximations of π, a drift of 0.00001mm is sufficiently close.

What About the Short Length?

Let’s take a moment to look at the short length and see if the level of accuracy between rotations and degrees holds.

Let’s start with rotations again. We know that a single rotation gives us approximately 216.14157mm of travel. We also know that our distance to be traveled is 3 feet or 762mm.

762 ÷ 216.14157 = 3.52546

This means the motor will need to rotate 3.52546 times to travel 3 feet. If we double-check this, we multiply our answer (total number of rotation) by the circumference (distance traveled by each rotation) and should get our total distance.

3.52546 X 216.14157 = 761.99845mm

When working with rotations on the shorter distance, our drift is 0.00154mm. This would mean that our total drift for the entire rectangle would be 0.0049mm.

(0.00091 X 2) + (0.00154 X 2) = 0.0049mm

Now, let’s look at degrees for the short length. Once again, we know that a single degree of rotation gives us approximately 0.60039mm of travel. We also know that our distance to be traveled is 3 feel or 762mm.

762mm ÷ 0.60039mm = 1,269.17503°

This means that if the tire rotates 1,269.17503°, we should travel 3 feet. If we double-check this, we multiply our total distance per degree traveled by the total number of degrees of rotation.

0.60039mm X 1,269.17503° = 761.99999mm

When working with degrees on the shorter distance, our drift is 0.00001mm. This would mean that our total drive for the entire rectangle would be 0.00004mm.

(0.00001 X 2) + (0.00001 X 2) = 0.00004mm

Which is the Best?

Well, if we look at which option gives us the most accurate result, working with degrees resulted in an answer that is only a total of 0.00004mm off while working with rotations results in an answer that was a total of 0.00490mm off. That is a total difference of 0.00486mm.

If we are looking for ease of calculation, the number or rotations requires far fewer calculations and in theory less possibility for calculation error.

A Local Robotics Competition

Background

The way that we are establishing our Computer Programming curriculum is as follows:

  • Year 1 – Computer Programming
    • Language: Python
  • Year 2 – AP Computer Programming
    • Languages: JAVA & Ruby

Our Problem

Because UIL uses JAVA as the basis for its Computer Science contests and TCEA uses JAVA as the programming language for their area robotics contests, there is nothing extra-curricular for the students in Year 1 of our program.

Possible Solution

I am thinking that we will implement a local robotics competition for our first-year students using the LEGO Mindstorm EV3 kits programmed using Python to solve a given problem or set of problems.

I’ll need judges from around the local and larger community to judge creativity, engineering, and coding.

Eventually, I would like to open it up as an invitational format that could generate revenue for our robotics program and provide a small thank you gift for our judges.

AP or No AP

Introduction

This week, I have had the privilege of working with some outstanding educators from across the country at the UTeach: Computer Science Principles AP training held in Dallas, TX.

At this training, we were preparing for the newest addition by College Board to their general AP offerings: AP Computer Science Principles.

On the first day, the presenter stated that not all schools represented were going to be offering this for AP credit and I was stumped. I could not figure out why you would not present a course as AP if you could. However, as the week went on, I realized that my own campus is likely one of the ones that will not offer it as an AP course.

Background (Course)

This course is built to be offered to students who would not typically take a Computer Science course. UTeach has based their curriculum on the University of Texas courseThriving in Our Digital World which is the mandatory Computer Science course for non-Computer Science majors.

Background (My Students)

The students I will be starting with next year have all self-taught themselves JAVA as part of an after-school club. They participated on their own at UIL district competition and advanced to compete at UIL regional competition! These students have a strong desire to refine their skills in computational thinking and program development.

The Problem

The AP Computer Science Principles course is language agnostic and primarily relies on block languages such as Scratch for its primary delivery. As my students have been working with a text-based language, this will feel like a substantial step backwards.

Also, the course will not adequately prepare my students for participation in UIL, which is JAVA specific. I feel that my students will derive more long-term benefit from preparation and participation in UIL than they would completing this AP course.

Administration Support

I am blessed to have an administration team at the campus and district levels who trusts my judgement to do what is in the best interests of our students. I have actually been told by one of my administrators, “My ego is not stroked based upon how many courses have the letters “AP” in front of them. Do what’s best for our students. That’s what I want and what I expect.”

The Decision

Currently, the decision has been made that we will be offering the following:

  • Computer Programming
    • 2016/2017 (Not AP)
      • Programming Language: JAVA
    • 2017/2018 and Beyond (Not AP)
      • Programming Language: Python
  • AP Computer Programming
    • 2017/2018 (AP CS-A)
      • Programming Languages: Python, Ruby and Persistent Parallels to JAVA
    • 2018/2019 and Beyond (AP CS-A)
      • Programming Languages: JAVA and Ruby

The idea is that the students entering Computer Programming in 2016/2017 will be formally learning JAVA. In the next year, those students will progress to the second-year course, which is aligned with AP Computer Science-A and will cover the languages of Python and Ruby with persistent reminders of JAVA. Students in this group will be the UIL Computer Science team for both 2016/2017 and 2017/2018.

The students entering Computer Programming in 2017/2018 will be learning Python while learning computational problem-solving skills. In the next year, those students will progress to the second-year course, which is aligned with AP Computer Science-A and will cover the languages of JAVA and Ruby. Starting in 2018/2019, when these students enter the second-year course, they will be the UIL Computer Science team. In all future years, the team will be comprised of students from this second-year course.

Long-Term Benefit

The hope is that students in this program will leave with truly marketable skills in JAVA, Ruby, and Python development.