Magnus effect integral help

Hello, I have been using a paper by @Ether ( paper: Ballistic trajectory with air friction drag and Magnus ) to try to simulate where a shot will end up depending on initial shot velocity, angle shot at, and spin of the ball, taking into account air resistance and the magnus effect due to the spin. This is done in order to eventually send these values to the robot mid-match so we would have an accurate shooter.

At first I used similar code to the code that is in the linked paper, but I was wondering whether or not it was possible to calculate the end result without having to actually run a whole simulation (in order to save time mid-match).

So I tried to solve the acceleration_x equation for v and then integrate both sides to get total distance travelled in the x direction. But I am left with an integral of a_x / v_x and am unsure on how to solve this since they are both are functions of time (or maybe they are functions of x?).

Is this even solvable without the simulation? I do not think it is. I just started learning integrals this year though.



I haven’t looked at that integral, but I suspect it will be rather lengthy even if you find a closed form. From a practical standpoint, you could run a bunch of simulations up front and interpolate among them when preparing to shoot. This would be simpler if you constrain one of the three variables (likely launch angle) to one or a limited number of values. In any case, you also have the mapping from your actual shooter wheel speeds to the actual ball speeds - there’s certain to be some slippage. At the end of the day, it’s likely to be best to build up tables of size and position of the vision target and angle/speed solutions that work.

While I applaud your ingenuity in finding the physics affecting a game phenomenon and attempting to integrate it into your robot design/programming, aerodynamic effects can be particularly difficult to get a handle on. Furthermore, some papers I was reading earlier about the Magnus effect on spinning tennis balls (I think it was mainly Aerodynamics of spinning and non-spinning tennis balls, but there were others as well) seemed to indicate that calculating the actual lift in our particular case might have some extra issues.

Long story short, the lift coefficient is presented as a monolithic constant in the paper you linked, but it might actually vary quite a lot. The original height of the fuzz on the ball, as well as how worn the ball is, affects how strongly it interacts with the surrounding air. Additionally, the relative spin rate changes based on where in the arc the ball is. As the total velocity decreases near the top of the arc, is the ball still spinning at its original rate, slowed by some amount proportional to the drag, or something else that still needs to be determined? Also, I didn’t find any data specifically for tennis balls spinning at the rates we might expect for common FRC designs (i.e. a spin parameter of 1, where the slow side has 0 airspeed, like a no-slip hood), so I’m just assuming that they have similar high-spin behavior to baseballs, since the effect was comparable at the lower rates. To make matters worse, it looks like we might be sitting right in the middle of a change in flow regimes, depending on whether you use a high or low estimate of the exact speed and surface texture.

Now, I’m no aerodynamics engineer and I could be wrong, but I do have a bit of background and the information I did find made it look like a thoroughly messy problem. Regarding the integral itself, it’s been a bit of time for me, and I didn’t look too deeply into it specifically, but it looks like the sort where I wouldn’t expect to find a reasonable analytical solution, many times over if you factor in the changing lift coefficient, seeing as it is multivariable and not reducible to a system of linear differential equations. Using a good numerical integration method (it looks like the original algorithm was pretty simplistic, but they added a better one later) sounds like the way to solve it, and I think you might even be able to offload the calculation onto the driver station computer since you aren’t dealing with a large data stream like for vision processing.

Getting back to the original purpose, improving the accuracy of robot’s launching of cargo, I think this is an ideal scenario for doing some experimentation and generating a mapping or lookup table from your sensor readings to your controlled values. You really only have one input, the distance to the goal, since the height and angle of the goal is fixed; you probably have only one or two values to control, wheel speed plus either angle or secondary wheel speed; and you don’t really care about everything that’s happening between the robot and the goal, just how to control the robot and getting the ball into the goal. The physics itself is really messy, to the point where even if you did this type of analysis for a living, I wouldn’t trust its accuracy without matching it to real launcher data with these specific balls in your specific launcher, at which point you could skip the whole physics simulation and just compare directly to that data.

This post got away from me quite a bit, so TL,DR: Unfortunately, this is an incredibly hard physics problem and there are methods that will get you more reliable predictions, so I wouldn’t bother with it in the context of FRC, especially for someone who is still learning some of the foundational skills. If you’re interested in the problem for its own sake, I can try to scrounge up some other research or answer some more questions about the research or my understanding of the physics, but I’m certainly no expert on the subject.

1 Like

Nope, you’ve taken a non-linear problem that doesn’t have a generic closed form solution (just a drag force proportional to velocity^2) and made it more complicated. This post is hopefully enlightening.

As others have said above and you’ve probably learned in school, this mathematically difficulty is a common problem. Simulation or doing a bunch of testing and table look ups (often both!) is how these kinds of problems get actually solved. Practically one of those cases where just using your shooter and recording the data for use in a look up table is probably the optimal solution for your robot, but it would be super cool if you used that data to improve your simulation too.

1 Like

Pro tip: run your offline simulation with and without the secondary effects (air resistance and Magnus effect) to see if they are even worth accounting for. If they are not significant you just made your life much easier.

I do this kind of test all the time at my day job when I work with computer models.


As someone who just started learning more advanced math and physics, it kind of hits me the wrong way that we know the ball will end up in the same spot each time given the exact same initial conditions and yet we cannot mathematically figure out where it will land.

Anyways, thanks for the detailed response. I think I am just going to end up using an interpolating table mid-match like you said since I would have to test my simulation results against reality anyways.

It ends up being a common theme that many of the differential equations describing seemingly simple physics problems cannot be solved analytically (that is you cannot just do a bunch of math and solve for x). I think its because a lot of the dynamics in our world are inherently nonlinear (squares, sines, cosines, etc appear all over the place).

The upside is that a lot of work has been put into creating very fast and robust numerical solvers for these initial value problems (IVPs) where you have initial conditions and an equation describing the dynamics of the system (usually some form of F=ma). So you can focus your effort on setting up the problem and then let the solver do the heavy lifting.

I think many of us are first exposed to these types of problems in a high school or college math or physics course where the focus is mostly on analytical solutions. So it can seem frustrating because anything nonlinear is most often brushed to the side as “very hard to solve” or “unsolvable”. This was certainly my experience until I got to later engineering courses where numerical solvers became the tool of choice to tackle harder problems.

TL;DR Do not despair that this is not analytically solvable, it’s an interesting and perfectly tractable problem from a numerical standpoint. But I would definitely agree that interpolating lookup tables are a good choice for your robot. Best of luck!


This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.