Engineer Models II TA Honors Experience: Week of January 26th

This first set of journal entries will cover the entire first three weeks of the semesters. For
this semester, I am a TA for three different sections taught by both Dr. Miller and Dr. Honken.
The students were assigned a project to interpret relevant data to the engineering grand
challenges and use it to support or refute a hypothesis related to these challenges.
I was fairly well prepared to deal with this project considering it was similar to a lot of
the work I had done on my last co op semester. The assignment required a good understanding of
menu statements, matrix indexing, Boolean algebra, and data set properties. The general solution
was for the student to import the relevant data sets and then select the relevant cells based on
Boolean algebra equations and matrix indexing
The students themselves are at a wide variety of skill levels. Ive seen groups put together
advanced solutions in a couple hundred lines of code and be done far before their lab time was
up. On the other hand, Ive had students that wrote 60 lines of code which only plotted two sets
of data five times without any kind of analysis performed on the data or even using the data that
was relevant to their hypothesis.
Throughout these three weeks a pattern of three kinds of groups became apparent. There
were groups who were perfectly prepared to handle the lab on their own, groups who would ask
a lot of questions and didnt appear to have a clear idea of how Matlab logic worked, and groups
who would grow frustrated and stop working on the lab but not ask for any help. Over this lab I
hope to improve these last two groups. I would like to see them be able to really understand
logically what is happening rather than just trying to ask their way to the solution. I would want
our discussions to change from trying to point them to a standard solution, to having them
explain to me how their logic and variables work and seeing if they can determine the problem
and solution just by explaining their code to me.
Moving forward, it will be important to start identifying which students are really
understanding what their code does versus those who rely on splicing together pieces of code and
hoping they work. I would rather see the students struggle a bit to get an original piece of code
working flawlessly rather than opening up a powerpoint and copying and pasting a premade
solution for their lab.

Engineer Models II TA Honors Experience: Week of February 2nd

This week introduced the first individual lab project. This gave me the first real
opportunity to see if any students had been relying on their group to get their last project done.
After the three lab sections, it became very apparent that several groups had one person carrying
the whole team and that their team members had not played a very active role in designing the
code.
I have decided to take the Transformational model of leadership that I learned last
semester during the class Exploring Leadership. This style of leadership is based upon a team
learning and growing together and is centered on the team members bringing each other up to
new heights. In these three sections, I hope to do this by encouraging students to share different
ideas and realizing that there is often more than one solution when programming in matlab. From
now on, I intend on helping students explore their own original ideas for a solution and
discussing the advantages and disadvantages of that solution. I would like to avoid having
students all solve their labs with identical solutions.
Unfortunately, this goal could not be met well this week. The lab in particular, a robot
arm simulation, was primarily based upon code contained in one of the lecture slides. Most
students quickly found the relevant slides and pasted the premade code into their solutions.
However, since most did not take the time to understand the code and mistook it for a definite
solution, very few of these groups had working code the first time.
I had to go around to many groups who were confused as to why they couldnt just copy
the lecture and expect it to work. I had every group carefully read over their code and I asked
them what was wrong with it. While a few groups could walk through and find the problem, I
ended up with a lot of blank stares and expressions that said solve this for me. I decided not to
just tell them that their code didnt work because the lecture slide code wasnt exactly the same
problem as the lab and instead had each group tell me line by line what was happening. With a
bit of hand-holding, most groups were able to realize their mistakes and correct them.
This week was definitely a different style of learning with the three sections. While
helping groups certainly took longer this way, I feel that helping them by walking through the
various debugging stages will be far more beneficial than just handing them a solutions manual.
Hopefully with more practice, most students will get to the point where they can easily debug on
their own and will only need assistance when it comes to planning out the main structure of their
code and tackling obscure coding issues rather than asking for help every time they experience
basic syntax errors.

Engineer Models II TA Honors Experience: Week of February 9th

This weeks lab was all about interpolation and how to apply it. Interpolation was used in
this lab to resize an image by making it bigger and filling in the newly created pixels based on
the average of the preexisting pixels surrounding the newly created pixels. The end result of this
lab was to take a color image of a butterfly and double its height and width.
Many students struggled with the basic concepts of matrices. While most could correctly
construct a matrix and display the original image, many did not understand the idea of mapping
one matrix to another. Mapping occurs by translating the values of one matrix to another by a
predetermined formula. In this case the mapping was from a size M by N matrix to a size 2M-1
by 2N-1 matrix. This mapping occurs by filling in every other row and column of the larger
matrix with the values from the original matrix and causes a value of zero to be found in the cells
between every entered value. Then by applying the correct interpolation function to these zero
values, the enlarged image could be produced.
Most of the problems in this lab were caused by students misunderstanding how to
correctly travel through the matrix to fill in the original values of the matrix. Because of the
mapping that occurs, students needed to travel through the original matrix one cell at a time for
the entire matrix but needed to travel through every other column and every other row of the new
matrix when constructing the enlarged image (mapping MxN to 2M-1x2N-1). Many students
also had a problem understanding that when working with a color image, the matrix had to be
expanded in a third dimension to account for the three different RGB color values in every pixel.
This resulted in many students producing red images because they were only using the first red
pixel values.
By the end of this lab I felt that all the students I had interacted with had a better handle
on matrices. Some picked it up immediately, but others struggled with it. I had to break a few
students out of the mindset of hardcoding these problems especially once images reached a
substantial size; I had to show them how to effectively use variable to indicate the row and
column they were operating in and how to map this variable to the larger matrix. Hopefully these
lessons will stick with all the students since matrix operations are the largest focus in Matlab
applications.

Engineer Models II TA Honors Experience: Week of February 16th

No classes due to snowstorms.

Engineer Models II TA Honors Experience: Week of February 23rd

Lab three was about estimating velocity and acceleration using different numerical
differentiation techniques. Three techniques were used to estimate both the velocity and
acceleration of an object and then were compared against the objects actual velocity and
acceleration. The three techniques were: two-point estimate, three-point estimate, and Simpson's
rule.
The goal of this assignment was to show how different techniques can be more accurate
when estimating derivatives of functions as well as how to estimate the integral of a function.
The two-point estimate is the least accurate because of the few points it involves, the three-point
estimate is slightly more accurate especially for functions that vary between increasing and
decreasing regions in the function. Lastly Simpson's rule is an effective way to estimate the
integral of a function by using three points along the function and approximating their integral as
the area under a parabola. Students were also supposed to see that by increasing the number of
points used to estimate the integral of a function that the approximation would be more accurate
to the actual integral, especially for functions with irregular shapes.
Nearly all students picked this lab up quickly. Most have seen some forms of these
equations before and have taken enough calculus to understand them even if they had never seen
these equations before. There weren't any major problems in this lab other than simple syntax
issues in writing the actual Matlab code. A handful of students had difficulty with plotting
multiples plots together or were having issues with not clearly their figures before trying to plot a
separate group of functions. Overall though, this lab was fairly easy for all the students to finish
and due to the snow days last week many had it already completed coming into lab. The majority
of students at this point seem to be back into the habit of coding with a purpose and planning
their code out before just writing random lines and hoping it all works out in the end.

Engineer Models II TA Honors Experience: Week of March 2nd

Edge detection is a new edition to models two that I haven't done before. The concept
behind this lab was to take a picture and place its pixel values into a matrix. A translated matrix
is made from this original by applying a filter to each of the pixels in the original which checks
the surrounding pixels to determine whether or not there is a significant difference in the pixels
values. The more of a difference there is the whiter the pixels in the translated image will be. The
translated image therefore becomes a black and white image where the white pixels correspond
to the edges of objects in the original image. Different filters can be applied to search for edges
that are horizontal, vertical, or both.
The methods behind this lab are similar to the interpolation lab. A matrix is created to
hold the original image and an empty matrix of identical size is created. Every cell in the original
matrix has a 3x3 matrix consisting of a pattern of integers that are either -1, 0, or 1 and each cell
around the focus cell is multiplied by these integers and them summed together. This sum is the
value placed into the corresponding cell in the translated matrix. The translated matrix can hold
pixel values from 0 to 255 with 0 being black and indicating that there is not significant variation
in pixel values around this point, and 255 being pure white.
This lab showed students that when using the horizontal and vertical edge detection
filters, not all of the edges could be detected and many edges weren't shown as sharply. To
remedy this a hybrid matrix had to be created which essentially was a diagonal edge detection
matrix in order to determine more precisely how many edges there were. Another issue with edge
detection is that simply summing up the result of multiplying the original matrix by the filter
matrix can result in values much higher than 255 or all pixels of less than 10. This means you
could potentially end up with an all white or black matrix that is not useful for determining
edges. To remedy this, the students needed to find the max value in the translated matrix and find
a factor that could scale it to the value of 255 and then multiply the value in all the other cells by
this factor. Once this has been done, the resulting image was shown to consistently display edge
detection for a variety of pictures: x-ray, brick wall, engine exhaust, and even a person's face.
Most students picked this lab up easier than the interpolation lab most likely due to the
extra practice and the ease of working with matrices of identical sizes. A few were also interested
more in the idea of edge detection; mostly computer science students who have been working on
more in depth programming assignments. The students also seem to be getting more at ease with
how to perform matrix operations, however this lab worked with purely integer values and there
was no mapping of time variables to matrix locations which is arguably much more difficult to
work with.

Engineer Models II TA Honors Experience: Week of March 9th

This weeks lab was all about falling objects and the effects that air resistance can have
on the velocity of the object during the fall and how this difference can affect the amount of
potential energy that is converted to kinetic energy. The goal was to show that as air resistance
acts as a force opposite to gravity and therefore as the object falls some of its potential energy
will be lost to the air resistance while the rest will be converted to kinetic energy. Air resistance
also increases the faster the object is moving and therefore the force acting opposite of gravity
will increase until it matches the force of gravity. This will cause the object to fall at a constant
velocity until it finally hits the ground. In the end, the students were expected to show that
without air resistance, the objects fall with a constant acceleration while with air resistance the
object will fall with a decreasing magnitude of acceleration.
No students seemed to struggle with this lab. Granted this lab was probably one of the
simplest and covered topics that all of the students had already done in Physics 1 lecture.
However I also noticed that very few students seemed to have any coding issues that commonly
occurred in the past. The biggest problem was students not checking for the point where the
object hit the ground and then setting the velocity and acceleration to zero at that point; some
groups had the object actually falling through the ground.
As this was the last lab before the GUI project, I was glad to see no students struggling
with the code and most groups ended up leaving lab early with the entire lab submitted. After
spring break they will begin work on their GUI projects which will be a much larger endeavor
with multiple functions working together to create a learning tool on concepts they studied this
year. Hopefully they will be able to recall all the concepts theyve learned so far and I hope to
see some truly great projects in the remainder of the class.

Engineer Models II TA Honors Experience: Week of March 16th

Spring break week.

Engineer Models II TA Honors Experience: Week of March 23rd

This week there was not much to reflect on due to the lab being just a continuation of the
lecture on Graphic User Interfaces (GUIs). All three of my lab sessions were for the purpose of
reviewing how GUIs work and having the students construct a simple GUI based on the
instructors directions. Since I wasnt working directly with students I took this time to brush up
on how GUIs work.
GUIs essentially are made up of a number of graphics which each correspond to a
collection of functions. Most objects that the user can interact with contain a callback function
which is executed whenever the user interacts with that object. Most of the time this is used to
alter a variable that is used in the rest of the functions such as a function to be displayed on an
axes or the velocity of an object that is being simulated for projectile motion. These values are
usually stored in a global variable called Handles which all of the function are able to access and
modify.
I can already foresee a few problems that students will have in this final project. The first
is that most students have never been introduced to functions and instead have been running
scripts the entire semester. I thought this was a mistake in the curriculum, and so I have been
encouraging students to start using functions instead so that they would become familiar with
how they work. Since they all have been running scripts instead, most students are probably
unaware of the scope of different variables and will make mistakes in using local and global
variables in the lab. They wont realize this is a problem at first since the code will still run, but
if they are incorrectly using a local variable instead of a global one then that variable will have
completely different values in the separate functions in the GUI. Many also wont understand
how nested functions work and so will try to treat all the functions in the GUI as being separate
instead of being nested functions within the GUI as a whole, this will cause errors in trying to
run the code.

Engineer Models II TA Honors Experience: Week of March 30th

Most of this week was spent helping students plan out their projects and determining
what all they would need to accomplish their projects. The project requires them to create a
working GUI to teach a concept they have learned about their freshman year which uses at least
two objects not taught about in the class. The groups for this project were pretty much whatever
lab group the students had been in for Dr. Millers section and groups assigned by Dr. Honken
for her sections.
Many students gravitated towards concepts already done in lab and I had to steer them
away from just turning their past labs into a GUI. Most of my conversations with students were
about how to expand on concepts to ensure that the GUI further explained concepts. Many
students were just going to have the GUI calculate and plot some values without showing how
theyre determined. I wanted to make sure for concepts like integral estimation the groups would
show the individual segments of the function being used to estimate the integral so that for
someone learning they could understand why certain methods are only estimates and how they
could underestimate or overestimate.
Animating concepts was also a point of interest for many groups. Showing waveforms
propagating over time, chemical reactions, cars traveling along a slope, and others left me very
optimistic about how some of the projects will eventually turn out. I showed these groups how
you could create an animation by using the axis object to plot points, lines, and images to
represent whatever it is they wanted to animate.
Most groups mainly used this section for brainstorming and determining who was going
to be responsible for which sections of the project. Because of this I was able to spend more time
working with a larger number of groups than usual and was able to get a good idea of what all
the groups were doing. I was able to get most of these groups on track to hit the ground running
next week when they begin programming. Many groups even managed to build the layout for
their GUI and ensure they met all the requirements of the project.

Engineer Models II TA Honors Experience: Week of April 6th

The goal of this week was to make sure every group had their layout finalizes and was
able to at least have their Matlab code generate a functioning GUI. Most groups at this point
have picked out their concept and were trying to define all the elements they needed in the GUI.
They are required to include at least two elements not discussed in lecture which has proven to
be more difficult than expected since most of the easier elements such as axis, edit text box,
static text box, and drop down list were already covered. Most students gravitated towards using
radio buttons to cover one of these elements, and then the second element used varied widely
between the different groups.
The lecture on creating GUIs seems to have stuck with everyone since there were very
few problems in getting the GUI to display in Matlab. A few students had problems with certain
GUI objects not showing up when the code was ran. No errors were detected in the code and it
was found that either the object was set to the back of the GUI and so was being covered up by
other objects or more frequently that the object had been set to be transparent. Eventually all of
these problems were cleared up with minimal effort.
Most groups started coding some of their callback functions during this lab session. Most
groups relied on a single GUI object running the majority of their functions: usually a push
button that was called something along the lines of calculate. For some groups this was just a
convenient way of trying to avoid coding in multiple functions and I steered them away from this
solution since it is unnecessary; for other groups that had functions simulating problems with
multiple variables, this solution is a necessity. If they did not have a calculate function, then
every time they tried to setup a new scenario the code would run every time a variable changed.
This would slow the whole program down and could potentially crash Matlab if all of the
variables were changed too quickly.
The vast majority of groups left in good shape today. They had their GUI being generated
by Matlab with at least a couple of components' callback functions working. Any remaining
components that hadn't been finished had at least been assigned to group members to work on so
that next week they could finalize their project. A handful of groups were found to be struggling
and we tried to work more closely with them this week. We got all of them to at least the point
where they were completing their first callback functions. Hopefully they will continue to work
on it outside of lab during the next week.

Engineer Models II TA Honors Experience: Week of April 13th

This week was the final week for groups to work on the project in lab. Next week they
will be demonstrating their projects to the rest of the class. Several groups came to lab with
working GUIs that just needed some aesthetic touch-ups and therefore were able to leave lab
fairly early. Most groups were nearly finished and had come to class with the remaining callback
functions they had separately built and were testing and debugging the finalized product. Then
there were of course a few groups who had a long way to go in the week that remained.
Most of the problems we took care of this week had to deal with common issues such as
linking together a slider and edit text box so that they could share a single value and whenever
you changed the value in one, the other changed to match. Another common issue was getting
axes to display correctly. Usually this was not a problem with the data, but rather changing colors
for multiple plots so that they could be easily distinguished or clearing the axes so that previous
data was not still visible. Most of these errors I had encountered before many times so fixing
them was fairly easy.
A few groups even stood out as going way beyond what was necessary for this project. I
had groups simulation chemical reactions and using the axis to show different molecules
interacting with each, groups animating sound waves, and even groups showing a car as a box on
a ramp and how it moved based on the friction coefficient of the ramp and starting speed of the
car. Overall many groups stood out and will undoubtedly have great presentations next week.
A few groups put off their work that they needed to get accomplished last week. So for
these groups this lab period was a lot more intensive as they tried to find bugs in their code that
kept crashing the Matlab GUIs. Ultimately most of these groups were able to get the GUI to
function properly by the end of the lab but they were for the most part much simpler than most of
the groups who had been better about sticking with the project timeline. I don't believe we had
any groups leave with a completely non-functioning GUI, and hopefully these groups will
effectively use the weekend to ensure their GUIs work for all the possible inputs and meet all the
requirements of the project.

Engineer Models II TA Honors Experience: Week of April 20th

This was the last week of models two recitation and was also the demonstration week for
the GUI project. There was quite a range in demonstration from those groups who just met the
project guidelines to groups who extended far beyond the requirements to create very
professional looking GUIs that could actually be used in a classroom setting.
There was not a single group I witnessed that didn't fulfill the requirements of the project
so I feel that overall these recitation were very successful throughout the project. I did not even
encounter an instance of a bug crashing someone's code when we tried to have the user input an
incorrect value into the GUI. Most groups took into account user error and coded to give the user
a warning message whenever their input was not acceptable. However, some groups may have
forgotten to do this and I just didn't catch it.
A few of the things I noticed during presentations however were that in order to boost
their projects, many students started changing the layouts to be more eye-appealing and started
incorporating colors to make certain sections stand out. While this was a good idea, most groups
didn't account for how background and text colors should be chosen to ensure that the visual
aspects do not detract from the function of the GUI. Many groups chosen very bright background
colors such as the true hexadecimal values for Red and Blue. Ideally in this setting, duller pastel
colors would have been a better choice. It would have not been nearly as bad had they switched
their text colors to white, but they left it all as black text which is very hard to read from a user's
standpoint. I made sure to address this to the class so that they know going forward that when
you create a tool for a user, that aspects like this need to be accounted for just as much as you
need to ensure that the calculations are accurate and able to handle user errors when dealing with
inputs.
Overall the labs presentations were great and the few groups that decided to add
animations in their GUIs did a very good job at creating a visual aid that would help a student to
learn the concept being taught. I have enjoyed TAing these sections this semester and I can
definitely say that the students have gained a much stronger grasp on programming and problem
solving fundamentals this semester. I hope to continue teaching these engineering models classes
in the future and improve my own understanding of Matlab as the course continues to evolve and
add new concepts into its curriculum.