Question Stewart platform forward kinematics

Unlike for robot arms where the forward kinematics (calculating t he position of the gripper from the joint angles) is easy to solve and the reverse is difficult (calculating the angles from a desired position) for Stewart platform it's the opposite. Calculating the inverse kinematics (what FlyPT Mover does) is easy. Just rotate and translate the rig to the desired position and calculate the length of the actuators (= distance of the end points in 3D space). That's straight forward and has only one solution that can be calculated by an explicit formula.

But how can the forward kinematics be solved? There are always at least two different solutions, one with the rig above and one below the base plane. If there are singularities there may be even more solutions. And AFAIKS, a system of non-linear equations has to be solved to find them.

Does anybody know a solution for this, hopefully a code snippet or Excel sheet? I need this to implement a collision avoidance system.

Forward kinematics is complex due to the coupled nature of the equations and typically results in multiple possible solutions (up to 40 in some cases). There’s no simple closed-form solution, so it’s often solved numerically or iteratively.

This is according to grok 3 ai. So it’s really ugly. Also fits with my recollection of the problem. Grok had more information but my eyes glazed over.

Sometimes you can find a more pragmatic solution which is good enough even though not comprehensive. Aka is the axes are in a preset range maybe there is a problem.

After thinking about this I believe it would be easier to so a man in the middle solution. So you redirect the output of DCS or MSFS to your application and receive the data coming from the game. You calculate the Cartesian position from that.

That’s not easy either especially if it’s doing a memory share. Anyway, that’s another way to solve the problem.

Yes, thanks, Joe. I scratched my head a bit and came to similar ideas. So I think there are basically two solutions that sound promising.

1. Calculate an approximation: If I assume that the intersection of the axes center lines of the actuator are at a constant distance above the upper joints the whole rig becomes a set of four triangles which is a lot easier to calculate. The three lower triangles (bottom=constant distance, upper 2 legs = actuators) with the actuators define three circles. All I have to do then is to find points on that circles with distances matching the upper triangle (connecting the intersection points). This should be possible numerically by taking the last position and move in the right direction iteratively.

2. Ignore the forward kinematics problem and transmit both the actuator positions and the raw data (heave, sway, surge, yaw, roll, pitch) from FlyPT Mover to my controller. Bandwidth is no problem but I have to make sure that my algorithm of how to calculate the reverse kinematics match that of FlyPT Mover.

Consider it an estimate. How accurate does it need to be?

BTW: What processor are you using?

I could also
3. Completely eliminate the kinematics calculation in FlyPT Mover and do all that on my own. So I'd only transfer the raw data (heave, sway, surge, yaw, roll, pitch) from FlyPT Mover to my controller. Then I can check for collisions, apply the required corrections/limitations and after that calculate the Stewart kinematics.

Probably Basti from Motion4Sim also implemented the kinematics in his controller for the same reason.

I know, FlyPT Mover V3.7 has an anti-collision feature. But I'm a bit sceptical. Hard limits to the position values don't help much. You also need to limit acceleration and that normally required look-ahead which we don't have. Adding filters to limit acceleration would add delay which we don't want. So the only way AFAIKS is applying clever speed limits that depend on the coordinates. That would result in a "soft clipping" that obeys acceleration limits.

PS: I'm using a Parallax Propeller2 (an 8 core 32 bit CPU with 64 bit CORDIC solver)

Well that’s a surprise. I am looking at a Teensy which has ARM Cortex M7. This is single core but it does have a DSP.

The Teensy also has FlexPWM hardware. This seems to provide easy frequency control for 16 output pins. I haven’t verified the “easy” part yet.