Comments on Projectile Motion, Part 2

[JacquesCarette]

• the graph could really use colour (or different kinds of arrows) as quite different things are being denoted by 'the same thing'. In particular:
  1. force (g)
  2. velocity (v^i)
  3. position (p)
  4. distance (d_{offset}), but that one is at least 2-headed
  5. axes (x, y)
  6. angle (theta)
• I was expecting the text to read even more in 'tutorial' style.
• in "Vertical Motion" you talk about the equations being redundant (so there' effectively only 2), but then the summary talks about 3 unknowns and three independent equations!! This is very confusing - but it turns out not to be false. This is because the motion equation are done vectorially, but this paragraph splits them up component-wise without saying so.
• "Procedure for Analysis" should either be given or deleted
• The 'sack' example threw me. The picture for the initial Projectile setup has 'ground' at y=0, and the projectile starts there too. But here the setup is different. The graph does not make it clear where the axis is -- I have no idea if it's the line labelled 'x' on the other one lower down.
• the setup talks about the equations of motion, but not the detection of 'collision' or anything, this is all implicit. This is especially clear when the Sack examples changes the picture quite a bit.
• the sack example introduces a distractor: dynamics that happens before our model starts. It's very confusing as it took me a while to understand what was in the model and what wasn't.
• in the sack example, there is a downward arrow labelled "a = -g". But in Projectile, the same downward arrow is labelled "g" !
• (v^i_A)_y ???? Wow, what a mess...
• there is missing traceability information: the link between the names of variables in the model, and the names of the variables in the Python code. There should be a table with all this information.
• the 'model' at the start substitutes in g for a, while in the example, the exact opposite convention is used. So the equations do not "trace" to each other.
• "Rearranging to solve" - there is no explanation for why this step is important. It's all tacit knowledge.
• "This calculation also indicated that..." again, tons of implicit stuff here, because that other calculation is not here!

[smiths]

• the graph could really use colour (or different kinds of arrows) as quite different things are being denoted by 'the same thing'. In particular:

  1. force (g)
  2. velocity (v^i)
  3. position (p)
  4. distance (d_{offset}), but that one is at least 2-headed
  5. axes (x, y)
  6. angle (theta)

I added colour to the figure showing the general motion of a projectile in b93be9f. Based on the comments though the figure that @JacquesCarette reviewed was the old version, which was simply borrowed from the projectile example in Drasil. The newer figure could still benefit from colour though, so I still made the changes. :smile:

The comments on the Drasil version of the figure are accurate, so I created an issue in the Drasil repo:

https://github.com/JacquesCarette/Drasil/issues/2310

• I was expecting the text to read even more in 'tutorial' style.

The text followed the original source. Now that we have the example, we can think about how to improve it to make it more tutorial style. As a start, I've added the "Procedure for Analysis" section in f887fa0.

• in "Vertical Motion" you talk about the equations being redundant (so there' effectively only 2), but then the summary talks about 3 unknowns and three independent equations!! This is very confusing - but it turns out not to be false. This is because the motion equation are done vectorially, but this paragraph splits them up component-wise without saying so.

In commit a2c76d0 I split up the discussion about dependent and independent equations to make the text clearer. I also added a point about horizontal velocity being constant, since Hibbler is actually silent on this point in his summary. We should think about whether this silence is confusing to new learners.

I'm going to stop at this point. I will address the rest of the points when I get back to this task. :smile:

• "Procedure for Analysis" should either be given or deleted

Added in f887fa0.

• The 'sack' example threw me. The picture for the initial Projectile setup has 'ground' at y=0, and the projectile starts there too. But here the setup is different. The graph does not make it clear where the axis is -- I have no idea if it's the line labelled 'x' on the other one lower down.

The previous picture for the initial projectile setup was just a placeholder. The figure has been updated to show that the origin and coordinate system. The text explains that the coordinate system location is a choice. Finally, the coordinate system is labelled in the figure for the sack example. I'm not sure where the ambiguity is. The x axes is the line labelled x. :smile: To help clarify the different lines, I changed the line style of the lines that are not part of the coordinate axes.

• the setup talks about the equations of motion, but not the detection of 'collision' or anything, this is all implicit. This is especially clear when the Sack examples changes the picture quite a bit.

I've added a bullet point to the "Procedure for Analysis" section to address what is mean by the significant points in the problem. We need to know something about the two points that are selected for applying the equations of motion, so that we can solve the equation. The following text is added in commit 63b6195:

• The two points that are selected should be significant points where something about the motion of the particle is known. Potential significant points include the initial point of launching the projectile and the final point where it lands. The landing point often has a known $y$ value.

• the sack example introduces a distractor: dynamics that happens before our model starts. It's very confusing as it took me a while to understand what was in the model and what wasn't.

Addressed in 3d61937.

• in the sack example, there is a downward arrow labelled "a = -g". But in Projectile, the same downward arrow is labelled "g" !

The previous general figure was just a placeholder. This inconsistency was fixed when it was updated.

• (v^i_A)_y ???? Wow, what a mess...

I can either get rid of A, or get rid of the i. I think I'll revise the equations to remove the i. The example talks about point A and point B, so reflecting those in the modelling variables seems to make more sense. I'll do this the next time I take up this task.

This has been updated in 2ff483d.

• there is missing traceability information: the link between the names of variables in the model, and the names of the variables in the Python code. There should be a table with all this information.

Added in 0ef82ac. Also added tables summarizing all of the symbols in the model. As a consequence of putting this table together some symbols were removed, like the vector r, which was replaced by p.

• the 'model' at the start substitutes in g for a, while in the example, the exact opposite convention is used. So the equations do not "trace" to each other.

Both equations reference the initial equations in terms of a. However, because it is easier to reference the first equations, rather than introduce another equations reference. (Equation references in markdown are awkward.) I will look at labelling the g versions of the equations and using those for the sack example.

These changes were made in a55eee5. The example uses the equations with g, rather than the equations with a. The connection is made explicit between initial values and Point A and final values and Point B.

• "Rearranging to solve" - there is no explanation for why this step is important. It's all tacit knowledge.

Addressed in 3776140.

• "This calculation also indicated that..." again, tons of implicit stuff here, because that other calculation is not here!

Addressed in 6487470.

All of the feedback from @JacquesCarette for this issue has been addressed, except for making the example have a more tutorial structure. A new issue will be created for that task.

[smiths]

Closed by creating #247.