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?