Calculative Design

[Ditchdigger]

I want to encourage something of my accompanying future engineers. I want to emphasize how beneficial and even important using math to guide your robot design can be. Math is a beautiful tool with which we may translate our mechanical world into a precise language. When you quantify your resources in that language you can utilize them in the best possible way. Because of that, you even realize how much availability in potential your resources really give you. Math can be utilized to guide or influence virtually any part of your design. I encourage you to not only come up with creative ideas, not only experiment unto trial and error, but to truly design for success and the subtly hidden but powerful optimizations.

Science is often divided between the theoretical and the experimental. Since it is the summer, I am restricted to the theoretical for now (so to speak). My team will get to start building when school kicks back up, but until then, i have no physical vex parts to play and prototype with. As I do my part of the planning for the robot until school DOES start, there is often the pressure of uncertainty if i can make the robot do all the things i want it to. I want it to do a lot. The Gateway Competition, as i see it, was crafted to push our use of the vex robotics system to a new level, to push the vex robotics system through its conventionally familiar limits, to call for our deeper creativity to address those limits. Every time i introduce a new idea with its calculating factors, ive found incredible relief at how much power these resources really have. You don’t have to settle for less than you want, you just have to be CREATIVE and CRITICAL enough to forge a design aspect that will achieve that goal. When my team and i get to start building, the parts won’t perform like new (they’re not) and the robot’s performance won’t match my figures to an infinitesimal degree, but for now i still hold the belief that preparing the design around mathematical figures will prove to be far more than just usably accurate.

To partly demonstrate this emphasis, I have done a fun little side project, a pseudo-robot design for this competition.

Because I have been lengthy, it must be truncated and is finished in the first reply to this thread.

This robot would be entirely expensive and not very competitive, however i am alright with that!
I am not here to give away valuable designs!
I am providing this example robot for those of you who would benefit from demonstration that these resources, the vex robotics system and its functions, can be put into numbers and used to accomplish your creative ends.
Beyond that, it seemed like a fun concept to plan out (i couldn’t get it out of my head until i did it), and i believe its worth sharing.

I’m into SI units, so any lengths are in meters and most other units are SI as well.

I have broken this design aspect into two parts.
The first part demonstrates how you can take provided information about your resources and make a prediction on how it will operate. It is subject to theoretical/experimental discrepancies. Actual practice may require calibration and re-figuring of information.
The second part demonstrates more generally that you can put mechanical events into equations and find literal solutions to your goals. Its discrepancies between theory and experiment are of the negligible level.
The math in Part 2 is certainly true, while the math in Part 1 may need to be slightly modified based on the conditions of how your resources actually perform, but is a good prediction none-the-less (i hope).

Suppose we want a robot that will launch the game pieces into the air and into the circular goals!
Its just like basketball.

Part 1

We must find the velocity of the projectile after being launched.

The vex store informs us that the maximum force exerted by the cylinder is 54 Newtons.
The store also informs us that it takes 45 strokes from 100 psi to 25 psi.
Furthermore we know that each stroke is 0.050 meters long.

We can model the pressure of the pneumatics system by (1)
However, if we use multiple cylinders to the same ends (or even multiple reservoirs for more air), then we must modify S as shown in (2)

We know the following physics equations:
pressureconstant=force
forcedistance=energy
kinetic energy=(1/2)mv^2

If the maximum force that can be exerted by one cylinder is 54 Newtons, our necessary assumption while restricted from experimental confirmation is that it is at 100 psi. We may now solve that the constant is 0.54 and multiply it with (2) to get (3).
To qualitatively understand (3), it is saying that if you have N1 amount of cylinders hooked up with N2 amount of reservoirs, and after the cylinders perform S amount of strokes, the next stroke will have (3) force to it.
This carries on to how much energy the cylinders can exert after S amount of strokes. We do this with that second physics equation, and just multiply (3) by the length of the stroke, 0.050 meters, to give us (4)

Interestingly enough, even if we set up the pneumatics to a lever or contraption to advantage either a stronger force or longer stroke (for more room for projectile acceleration), the force and stroke behave like a seesaw, advantaging one disadvantages the other. This amounts to the fact that the mechanical set up of how the pneumatics exert the force on the game object “doesn’t matter” (with a few minor exceptions like lever use conventions and) except that the more complicated it is, the more friction develops.
Basically we don’t need to set up any mechanical advantage to anything. The amount of energy that the cylinder puts out is how much energy will be given to the game object, especially if it is as direct as possible.
That is the same as saying
cylinder energy * amount of cylinders = kinetic energy of projectile (game object)
which gives us (5)

What we need to notice about (5) is that it contains real world data.
We can solve it for V and get (6)
And you see that if you have
a number of cylinders
a number of reservoirs
an amount of strokes already performed (even if its zero)
and the mass of a projectile,
then we can plug in the values and be given the velocity that the object will travel!
The number of cylinders and reservoirs would be data you set as constants in the program after building the robot. The number of strokes performed could be kept by the program. The mass of the projectile could be selected in the program as either the sphere or the barrel with either sensors or the driver’s indication with the remote control.

Part 2:

[Ditchdigger]

Part 2

We have solved for the velocity of the projectile. We don’t really get to choose the velocity. As we perform in the game, the amount of strokes grows, we switch between barrels and spheres, and we have a defined number of cylinders to work with. I’ll say it again. We don’t get to choose the velocity of the projectile. As we perform through the game, however, we encounter circular goals of multiple different heights, and with a varying velocity that we can not choose but only predict, how do we know what angle to launch the projectile?

Consider again this picture

It is set up this way in order to be calculable. The robot has a set distance between the launch contraption and the goal. It does so because the robots chassis reaches out and centers the entire robot on the goal. This tool means we dont have to worry about side-to-side accuracy, but also gives us a constant for the horizontal distance between the launch contraption and the goal, as i said. Furthermore, the launch contraption rotates its angle AT THE POINT OF LAST CONTACT WITH THE PROJECTILE for while a projectile is being launched. THIS IS VITAL because we want the point between pneumatic acceleration and gravitational acceleration to be INVARIANT, that is to say we want it to launch from the ‘same place’ no matter what the angle of the launch is.
If we consider the 2 dimensional projectile path to the goal with a coordinated mindset, we may call that point the origin.
The entrance to the circular goal can be considered as at the point (x,y) in this coordinate system relative to that point (the origin).
Thus, our robot will have
a constant horizontal distance
a vertical distance that must be selected/determined because the goals are at different heights
a velocity determined by s,n, and m
and a launch angle which we have not yet solved.

The above is described in this picture:

Now we have a set up that we can use to solve for the angle!
We will use only x,y,v,θ
and understand that l,g,m,n,s,h
are represented by those.

We start with (1) and (2)
The projectile is at a velocity. The projectile’s position needs to intercept (x,y). If the projectile is launched at an angle, which we know it is, then we know we can find its x position using its velocity (if we include time, t) and cos(θ). Cos(θ) is to show that the horizontal velocity of the projectile is only the component of the velocity that is going horizontal. I may sound redundant but i want make sure what is happening is clear. That gives us (1)
The vertical position, y, is different, but related. We model the y position similar to the way we do with (1), but the included term with k in it is gravity, and k is the gravitational constant.
What we don’t like about (1) and (2) is the variable t, time. We don’t need to know the time, and in fact, it is called an idle variable. All we need to know is how x relates to y. Luckily, t is easy to get rid of. If we solve (1) for t and plug that into (2), t disappears and we see how x relates to y.

This is actually a big deal. If you notice, (3) is what we’re looking for.
g and h give us y. L gives us x. m and n and s give us v.
The ONLY unknown value is θ, and all the numbers to solve for it fit in the relationship right there!
Unfortunately, solving for θ (or rather, extracting it to one side of the equal sign so we can perform the above sentence) is not as simple as getting rid of t was.
Solving for θ is not as simple because of the separation of the cos(θ) and tan(θ) terms. As you may know tan(θ)=sin(θ)/cos(θ). Because of that, we can solve (3) for either sin(θ) or cos(θ). IF and WHEN WE DO THAT, we will not have pure solutions for θ, but rather we will have 2 equations that say θ is equal to a function that uses θ, as modeled in (4).
Note that (4) has two equal signs in it.

I encourage you to reach those solutions on your own paper, interact with the math here so you can truly understand it rather than blindly follow my terms.

(4) may not be visually appealing, but the fact that it is solved for θ holds great power. Since θ is now solved for functions of θ, we can plug (4) right into itself. Specifically, if we plug the asin side into the acos side, (by the boxed conventions) we reach (5).
WHAT IS SPECIAL ABOUT (5) is that there are no more sin(θ) functions! Every time you see θ it is with cosine, which allows us to simplify.
(5) may not be visually appealing, but it is not in its simplified form (aka it has inner beauty, as you will see in the next sentence!). Because of how (4) works, we find whopping cancellations and simplifications in (5) that breaks its outer disgusting-ness all the way down to (6)!

I ENCOURAGE YOU TO TRY IT YOURSELF it is amazing

do it

(6) isn’t so bad looking, but it is still not solved for θ. If you examine its terms, however, you see frequent terms and ratios. All cos(θ) functions are squared. Every k is divided by v^2. Every x is squared. Because of this, I decided it would be simpler, for myself at least, to do temporary substitution, as circled to the right of (6).
That puts us at (7)
In order to solve for θ, we have to solve for cos(θ) first. Under my temporary substitution, this means solving for D.
It is very obscure in (7), but if you multiply both sides by DF, solve for zero, and factor out the D terms, you get (8),
A QUADRATIC EQUATION with D as the variable!

Remember that we are trying to solve for D? Well we all know that quadratic equations are very solvable!
Solvable with the none other than the QUADRATIC FORMULA of course!

By plugging (8) into the quadratic formula, you greet an equation that has D on one side, and E, F, and y, on the other. By re-substituting the original terms k,y,v, etc we have an equation solved for cos(θ)^2 which is then easily solved for θ which gives us OUR FINAL ANSWER which is (9)

For the sake of programing, it may be simpler to solve for θ with (9) in stages rather than all at once, possibly even with the substitution i provided. However, if you want 9 in the substitution terms, I encourage you to do it yourself. Ive done most of the work in this entire process for you already.

There is something key about (9) you need to notice though. There is a plus-minus sign. (9) does in fact give us two values for θ with that plus-minus sign.
Consider this graph:

[http://i51.tinypic.com/2100vuf.jpg

The vertical and horizontal lines indicate our goal point. The two slanted lines are at the two angles that (9) gives us. The two parabolas are the paths that a launched projectile would take. Both parabolas have the same “velocity”, but they exit the origin at different angles. They BOTH intersect the goal point. (9) gives us two answers for the angle because we can hit the goal point from ABOVE or BELOW. Of course we want to hit the goal point from above, and, if i remember correctly, you get the correct angle to hit it from above if you SUBTRACT at the plus-minus symbol. Someone might check if that is true for all cases though.

SUMMARY OF OPERATION
Our robot is in the middle of a game.
Our robot’s N1 number of pneumatic cylinders with N2 air reservoirs have performed S amount of strokes (scores!) so far.
We operate our robot to go install either a barrel or sphere into the launch contraption.
Either sensors or a driver indication to the robot through the remote tells the robot which one it is so that it may know the piece’s mass.
Because of the information our robot now knows, it calculates the predicted velocity of that given game piece after being launched, as seen in Part 1.
The launch contraption pivot point is H above the ground.
We built the robot with a forward reaching L long chassis that greets any goal it runs into.
We run our robot into a goal.
The driver indicates through the remote which of the three heights the circular goal is, G.
The robot finds X and Y because Y=G-H and X=L+(goal’s outer radius)
The robot was provided the gravitational constant k.
The robot plugs k,v,x,y into (9) (all at once or in stages) and sets the launch contraption to that angle.
The robot fires the pneumatics and the game piece flies into the goal.

CONCEPT SUMMARY (Part 3)

This is not the design of a complete robot, but rather a design aspect, the main concept. It is without a drive train or loading system.
Even then, i only explain two parts of this design aspect where math can be used. I assure you math can be used in as much of the design as you want, like in the drive train or loading system, or even further into main launch principle.
You could solve for gravity resistance while at any angle -during- the launch. This would fix a current (very slight) theoretical-experimental discrepancy. You could feature an inequality that alerts you when you don’t have enough velocity to reach a certain goal height. You could find more accurate ways to describe the cylinders’ power if you solved for their internal springs’ constants and rest displacement.
You could use math in your structure, not just physical functions. You could decide where to place weight. You could tell if that axle was going to snap. You could fix structure at the most effective angles to hold a force.
You can use math in as many parts of your design as you want, and i assure you there are benefits. I encourage you to not be afraid to jump into it, its not strictly complex like parts of my example, and it doesn’t take a nerd to make some figures work.

Im not really asking any questions, and at this point do not intend on sharing my actual robot plans, but i would love to hear your inquiries or input into the discussion or help you find a way to use math to your advantage! It is as good a resource to your design as the experimentation that will follow it.](http://i51.tinypic.com/2100vuf.jpg)