distance along an ellipse arc (nD Nonlinear System Solver (VI).vi)

[cbl-jnj]

I'm hoping to get some help solving an issue I've come up against. I appreciate that what I'm asking requires some of your time, so I've tried hard to do my due diligence before posting here. I'll really appreciate any help I can get. I'm using LabVIEW 2014 Professional on Windows 7.

I've stripped away all the details of the specific application I'm working on and tried hard to isolate just the issue that is causing me difficulties.

I've posed the problem below and I attached some investigation code (sorry, there is quite a bit) that represents my current solution (with the issue).

Problem: Given an ellipse (with a major and a minor axis and a frame of reference), a distance to travel and any point on the ellipse, calculate the end point on the ellipse where the elliptical arc length between the two points equals the given distance to travel.

I'll restate the problem, but with physical values. Given an ellipse, centered on the origin, with axes of 10mm and 8mm, and a starting point (5mm, 0mm); what is the end point on the ellipse after travelling 1 mm along the ellipse?

This initially seemed like a simple calculation (and it is for a circle), but for an ellipse, the math turns out to be somewhat more complicated and requires numerical computation.

Issue: I was given some python code that solves this problem and embarked on a LabVIEW solution. The python code uses the function optimize.fsolve from the scipy library to solve one aspect of the problem. I'm not too familiar with the LabVIEW VIs available to do the equivalent, but settled on "LabVIEW 2014\vi.lib\gmath\zero.llb\nD Nonlinear System Solver (VI).vi" (my code still has other options disabled in the code). When I use this solver VI, I do not always get the same answer from this VI. Sometimes it finds one root and sometimes two. For points separated by less than half the circumference of the ellipse, there should always be 2 roots (one in the clock-wise and one in the counter clock-wise direction). Any ideas why the solver does not always return 2 roots?

Current Solution: My investigation VI takes two points on an ellipse (defined by a start angle and end angle) and calculates the distance between them along the ellipse. Then, I take the start point and the distance and try to calculate the end angle (which I can use to find the end point). Run once, it usually finds the right answer, but run 100 times it often returns the answer 19. I should mention that I'm not 100% positive there are no issues with the code used to support this calculation and I'm open to any suggested changes or improvements, but the issue currently causing problems is the inconsistent operation of the solver VI.

Again, I appreciate this is long and thank you for reading this far; I hope you find this as fun a problem as I do!

Chris

[Dado.MB]

Hello Mark,

Thank you for been so keen on describing your issue. Now please tell me if I am wrong but basically your issue is about the "nD Nonlinear System Solver.vi" and its results. Now I would suggest you that please review the information on this VI exactly and looking over it, I see that it has a randomly chosen start point in n dimension, that could be the reason for the difference on several iterations running your application.

http://zone.ni.com/reference/en-XX/help/371361L-01/gmath/nonlinear_system_solver/

You could also take a look on this example using the VI:

https://decibel.ni.com/content/docs/DOC-2297

I would like if you would explained what is your final goal adressing this matter, as you posted yourself the current solution that you have done.

Regards,

David M.

National Instruments

[cbl-jnj]

Hello Mark,

Thanks for your reply, I was concerned that I had sent up an air ball on this one! And thank you for taking the time to review the code.

You are correct, I am having an issue with the results of the nD Nonlinear System Solver (VI).vi. And that is a good poiint you raise, regarding the choice of the starting points. I'm not intending to use random values, I think I'm using a number very close to the start angle (in this case 20.001 degrees) as a start and 2pi (or 360 degrees) as the end. When I read the description of the start and end from the documentation:

	Start is an array describing the left corner of the n-dimension interval. The randomly chosen start points of the zero-finding algorithm can be found in the n-dimensional rectangle spanned by Start and End.
	End is an array describing the right corner of the n-dimension interval. The randomly chosen start points of the zero-finding algorithm can be found in the n-dimensional rectangle spanned by Start and End.

I have to admit I don't *understand* what this means and I am currently guessing for the choices of start and end. I will think on this some more and review your links.

As far as my final goal, I'm going to use this code I shared for generating an ellipitical motion profile on the PC to send to a cRIO and have executed on a FPGA.

I'll report back after I work on this some more, but if you have some more insights, please share.

Chris

(BTW, I have an open support item for this #7444649 and it was suggested I also post on the forums)

[Bob_Schor]

Chris,

     I'm very impressed that you are using "Elliptic Objects" -- very elegant.

     I'm not sure what algorithm is being used for the non-linear solver, but by restricting your Start and End box to be very close to what you think is the "right answer", you are constraining the solver to only give you what you think is the right answer.  As you probably know, non-linear solvers like to "wander" over the solution space, "falling into the hole that is the solution" during their travels.

     I'd try widening your starting search box a bit -- I'll bet that gets you both solutions, and probably with little difference in accuracy.

Bob Schor

[cbl-jnj]

Hi Bob,

Thanks for taking the time to review my code -- it struck me early on that using a LVOOP class for a general ellipse made some sense here (and part of what makes this problem fun!).

I've learned some things regarding this solver VI and will post another zip (of a working version) later today or tomorrow. Basically though, the solver picks random starting points (the default is 5 for the number of trials) from the Start and End range. For this ellipse example, if those five random starting points are less than 20 degrees, than only the 19 degree zero is found. This random feature is the issue that is causing me problems, and it is true that raising the number of trials helps. I initially missed this from the VI help;

The algorithm used to find the solution to the nonlinear system is fundamentally stochastic in nature...To improve the chances of finding all solutions, increase number of trials.

However, this feature slows down the algorithm if I increase the number of trials and it turns out if I rewrite the solver without the random feature, I can get more consistent results. This is what I will share.

Chris

[cbl-jnj · Accepted solution]

As promised, here is a working version of the code I had posted earlier. This code always finds the correct answer, where before it sometimes did not find the correct answer. See my above post for detail about what has been changed.

Also, I was initially wondering what the LabVIEW equivalent to python code that uses the function optimize.fsolve from the scipy library. I believe the answer is

nD Nonlinear System Single Solution (VI).vi

as its inputs most closely match and seems to perform similiarly. It is where I'd start in the future and works well for now.

Thanks,

Chris