Minibot Ramp

[Richard Wallace]

Originally Posted by Duke461

... on wikipedia it says the Cycloid is for "the curve of fastest descent under gravity". Does this method still apply for upward descent?

The cycloid curve solves the classic (~300 year old) brachistochrone problem. The important feature of a such a "curve of fastest descent" it that it converts all of the falling particle's energy from vertical to horizontal motion in the least time. Applying the same criterion in reverse, to convert a minibot's energy from horizontal to (upward) vertical motion, will yeild the same curve.

[Duke461]

Originally Posted by Richard

The cycloid curve solves the classic (~300 year old) brachistochrone problem. The important feature of a such a "curve of fastest descent" it that it converts all of the falling particle's energy from vertical to horizontal motion in the least time. Applying the same criterion in reverse, to convert a minibot's energy from horizontal to (upward) vertical motion, will yeild the same curve.

Ah. Thanks for all the help.

[EricVanWyk]

Originally Posted by Richard

The cycloid curve solves the classic (~300 year old) brachistochrone problem. The important feature of a such a "curve of fastest descent" it that it converts all of the falling particle's energy from vertical to horizontal motion in the least time. Applying the same criterion in reverse, to convert a minibot's energy from horizontal to (upward) vertical motion, will yeild the same curve.

The cycloid is optimal for an unpowered e.g. object, such as a rolling ball. Is it still optimal when the object is powered?

[Ether]

Originally Posted by EricVanWyk

The cycloid is optimal for an unpowered e.g. object, such as a rolling ball...

A (frictionless) sliding ball. Rolling - I don't think so.

Is it still optimal when the object is powered?

No.

[Richard Wallace]

Originally Posted by EricVanWyk

The cycloid is optimal for an unpowered e.g. object, such as a rolling ball. Is it still optimal when the object is powered?

To answer this one, begin by writing an equation for the minibot's speed as a function of its height. How does the power contributed by the minibot motor(s) influence this speed function? Does the minibot's initial speed at the moment it crosses the deployment cylinder (tower base) matter? If the speed function has the same form as that of the unpowered object, namely the inverse square root of the object's gravitational potential, then the curve of quickest ascent will be a cycloid. See this reference for Bernoulli's reasoning, based on conservation of energy.

If you like this kind of problem, try your university's course in Calculus of Variations -- generally a graduate-school topic for engineers, or an advanced class for students of applied math.

[Ether]

Originally Posted by Richard

If the speed function has the same form as that of the unpowered object, namely the inverse square root of the object's gravitational potential, then the curve of quickest ascent will be a cycloid.

In other words, no. :-)

For high-school students interested in math and/or physics, the attachment shows how to use high-school-level calculus to figure out the travel time from point A to point B for a particle sliding down an arbitrary frictionless curve. You can replace f(x) with a straight line or a parabola or a cycloid or whatever and see the difference.

[James Critchley]

Okay. Step 0 should be to actually define the math problem we are trying to solve. I believe we can put that within the reach of high school math. Here goes...

In optimization we construct a "cost function" and try to minimize it... nobody ever wants to maximize the cost they pay. You can maximize its negative, would that be a "profit function?"

Anyways, the cost function we have here is the total time from breaking the plane on the tower to the top of the pole. We can divide the motion into three parts:

(1) flat extension to the ramp (start with a non zero initial velocity when breaking the plane)

(2) transition to vertical (the ramp). Beginning with the speed and position where the last segment left off. We further assume the ramp must be tangent to the horizontal at the robot side and tangent to the pole at the pole. This is known as a "constraint" and we can consider any solution as long as this is true. We have another constraint in the form of <g22> so assuming a 6" mini-bot, the ramp cannot extend beyond 12" maximum.

(3) vertical assent (the pole). Beginning with speed and position where the last problem segment left off, climb what is left of the pole.

Then recording the final time is the cost function.

We must be careful about optimizing a subset of the problem, such as the transition to vertical (the ramp), because it could lead us away from the best total solution.

One can imagine a solution which starts on the ramp much earlier and takes longer to traverse (the ramp), but has a shorter total time.

One can also imagine a solution which leaves the ramp at a later time, but with a higher speed and passes all other bots on the way up.

Given these three stages of motion, your next task is to come up with "good" models of the mini-bot behavior in each.

Example 1:
Let us assume that the mini-bot has reached terminal speed when it crosses the plane and that the terminal speed can be approximated as the same constant value when moving horizontally and vertically. This is actually a good model if we've got a really large a gear ratio on our mini-bot. In this case, the time to the top is the total distance divided by the constant mini bot speed. The minimum time is therefore the minimum distance, a straight line!! But subject to our constraints, you end up with a straight line ramp from the edge of the mini-bot tower to 12" up the pole with infinitely small fillets (rounded bits) on the ends to make the motion "smooth." Clearly our notion of smooth was abused by this solution, so we need a better model... some kind of penalty for less smooth motions. If you were to restrict the radius of curvature not to go below 2x the "wheelbase" of your mini-bot, then the solution is a smaller straight portion with fillets of 2x the wheel base.

We were able to solve this in our heads and we actually solved this like a real "calculus of variations" problem but only because the answer was obvious.

Example 2:
If your mini-bot cannot be approximated as a constant speed machine, then your first model would likely involve a solution for acceleration as a function of speed and incline angle (a = F/m where F includes gravity and the speed dependent thrust of the motor). 302 has a mini-bot spreadsheet which numerically integrates (calculus) such expressions for mini-bot pole climbing and you don't need to know calculus to understand it. Anyways, if we set one of those up, then we have the cost function.

This type of cost function is not generally amenable to working out by hand via the calculus of variations. However, you can greatly simplify things for the computer, allowing it to finish computing in your lifetime, by using those methods. Instead I'll describe the "brute force" optimization approach.

Once you have the cost function, you can change the values of the inputs (the ramp shape) and see what the final time is. if there were only two inputs (x and y), then cost (time) gives you a third value (z) which is like a topological height map of mountains and valleys. Extending this analogy, a numerical procedure "walks" down the hills and stops at the bottom of the nearest valley. Different starting points potentially land you in different valleys... so you need to "explore" a bit. The number of variables describing our ramp will be more than 2 (we'll use a many intermediate points), so it's difficult to visualize it as any kind of "terrain", but numerical procedures don't care and figure out which "direction" to walk (sometimes randomly!) and eventually find their way to a bottom. The best bottom you find is the solution you would use.

That's how you would solve the problem. Do you want to setup a spreadsheet to define the cost function?

[Tom Line]

Originally Posted by gblake

If I remember the rules correctly, any ramp or similar device is not allowed to have any effect on the minibot's speed.

Ramps or the deployment methods are only allowed to move the minibot into a legal "deployed" position.

From that deployed position the minibot has to climb without carrying any momentum or other assistance across the interface between the deployment process and the climbing process.

So (if I am right) I think your question is irrelevant?

Blake

Our team thought the same as you. When we saw several 'ramp' teams at championships who had a significant downward angle to their ramp so I questioned the lead inspector in Archimedes. Several of these teams were among the fastest in the field, and the downward angle allowed them to use larger axles (gravity helped the acceleration of the bot).

He confirmed that gravity CAN be used to accelerate the minibot (again, according to the lead inspector).

Had we understood that intricacy of the rule, we certainly would have gone ramp and our deployment would have been very very different.

Anyway - thanks for the cycloid. I wasn't aware of the interesting history behind it.

[Jared Russell]

Originally Posted by Tom Line

Our team thought the same as you. When we saw several 'ramp' teams at championships who had a significant downward angle to their ramp so I questioned the lead inspector in Archimedes. Several of these teams were among the fastest in the field, and the downward angle allowed them to use larger axles (gravity helped the acceleration of the bot).

He confirmed that gravity CAN be used to accelerate the minibot (again, according to the lead inspector).

Had we understood that intricacy of the rule, we certainly would have gone ramp and our deployment would have been very very different.

Anyway - thanks for the cycloid. I wasn't aware of the interesting history behind it.

In these cases, I'm assuming the minibot was under 30" from the ground at all times, correct? If not, one could argue that <G22> was being violated.

[Tom Line]

Indeed, in the instances we questioned they were under the deployment line at all times.