FlyPT 6DOF/Stewart/Hexapod Interface for linear and rotating actuators

Currently in the FlyPT mode, I'm using 16 bits, but I only use a small range. Since I needed 2 bytes to send the info, why not use all the bits.
The way it works, needs the same bit range for send and receive, because I'm comparing the values to calculate speed.

I think using the board for speed calculation is better.
I don't know the board well, but it's certainly faster to make it there and without problems of communication.
I even got a STM32F4 to make it, but I need some free time for that.

Advantage of my method might be the PID tuning (real time adjustment/results), but that's something that we need to make one time and leave it.

For those using Arduinos or something similar, my solution could be interesting, but mostly to achieve a speed calculation that relates all actuators (you can't connect all actuators on the same board).
In practice, we receive so many position updates from the games, that this speed calculation might not have any interest in this application.
But imagine another type of application that sends periodic positions and needs smooth transitions between positions, then we need that feature for sure. Something like a CNC hexapod based machine.

I am asking because while traveling from one extreme pose to another, the platform is "swimming" a bit. I have the feeling that the arms which have a smaller distance, are reaching their destination a bit faster than those witch has a big travel to accomplish.

Also the derivative value while set on the board, (tuned with heave dof) works accordingly to the weight which is distributed equally in this scenario (heave test).

Once you start to move your platform, the weight distribution of the actuators can change drastically (from much bigger to almost none) Would it be relevant to calculate the PID dynamically according to the weight distribution ?

I am not sure if it is a board pid issue, the lack of max speed of my motors or the way how the speed is being calculated.

Is there any solution to solve this issue ?

The second topic which confuses me a bit is the debug output which displays 8 bit values. As I said, we are suppose to use 12 bit values from the sensors. Does it make sense to make them match?

I am sorry I am not an expert in that matter. Just trying to engage a discussion, get some answers for better understanding and finding the eventual solutions.

I would be glad to have your opinion. Maybe @Thanos could also participate as for sure he would give much more precise information than me.

Thanks a lot - Cheers

Yes, that's the reason I made that speed control.

What I make is pretty simple.
I only have speed control on my controllers, so since P is the predominant factor in PID, if an actuator lags behind, in the next loop of calculation he might get a speed increase.
With cheap controllers, I can't get them to have matching speeds. They don't answer the same way to the speed input, there are differences.
Only match is steps I get from the hall sensors. So if one is getting behind in steps, the distance to travel increases and I increase the speed.
What I make is test witch actuator as more distance to travel.
Calculate the PID for that one (can be maximum speed or a low speed if near destination)
Interpolate that speed to the other actuators, depending on distance to travel.
That way, if one of them goes to fast or lags behind, he's corrected in the next loop.

Data is sent in bytes. Each byte is 8 bits, so blocks of 8 bits. One byte can send a value from 0 to 255.
That's what I show in debug.
When you send in decimal/text each char uses 1 byte also.
To send a bigger value you need more bits.
So:
8 bits = 0 to 255 = Maximum value of (2^8)-1
10 bits = 0 to 1023= Maximum value of (2^10)-1
12 bits = 0 to 4095= Maximum value of (2^12)-1
16 bits = 0 to 65535 = Maximum value of (2^16)-1

If I use two bytes (16 bits) to send a value, you need to multiply the higher byte by 256 and add the lower byte.
So:
123 200 => High byte = 123 and Low byte = 200 => Value=123*256+200=31688

The bytes could have the opposite order, but I use first the high byte and next the low one.
Bytes can only old a value up to 255
So:
255 255 => High byte = 255 and Low byte = 255=> Value=255*256+255=65535

And if we use 32 bits (4 bytes)?
255 200 123 100=> ((255*256+200)*256+123)*256+100=4291328868

As we can see, more bits, more resolution possible.
If we use an Arduino Uno with a pot, we can get a range of 0 to 1023. That's 10 bit resolution.
To transmit that data we need two bytes to old the 10 bit value.

We could compress that info and for 6 actuators * 10 bits, we need 60 bits, that's 60/8=8 bytes instead of 12, but then you need math to convert the bits to usable values...

The AMC1280USB calculates the PID position internally based on calibrated values. Its not receiving the position calibrations from the PC, but rather the target positions of the actuators.

Thanks a lot for your answer.

Is there no way to modify the amc so it uses the calculations based on position?

Maybe by letting do the Pid loop in the software or something....

For better movement accuracy, If only there is a technical possibility to use Flypt speed control with @Thanos board, I would love to give it a try.

Maybe we could use a second PID loop or bypass the internal PID to reach this goal.

@Thanos , @pmvcda , If it’s to much hassle (to much technical obstacles) or the relevance in your opinion is to low (benefit vs risk) I would still love to hear your expertise in that matter guys.

Thank you very much and sorry for bothering

Best

No, the PID loop in closed inside the AMC. It only accepts target positions. Send to is more detailed target positions closer positions to each other and you will get slower speed. Send to it large differences between positions it will go max speed. The speed is handled by the PID.

@pmvcda sends pre-calculated steps to his servos so half of the PID is open and thus he is sending the speed as well to manage the rate of the steps to the servos based on the pulses feedback from the servos. At least that's how I see it work for his servos.


Thanks
Thanos

It's different, I don't see how to use it and no benefit.
What I make is calculate speed with PID.
PID uses the current position received from the board and the position we want to calculate the speed.
I could send just speed to control the board, but, I also send position.
My controller has one input for speed and another one for direction. So it made me go that way.
I'm using position just to decide direction, But It's a stupid consequence of how I started the code.
I could make it faster and with less data needed, just by sending speed.

It can be done on a microcontroller without using Flypt speed control or a second PID so I don't see why it couldn't be done on the AMC too. Consider motor control is not limited to using P, I, and D only.

Thank you for your time and pedagogy.

I understand that the AMC also knows the current position of the arms from the feedback sensors and comparing the gap with the assigned position, sends the speed and direction back to the arms. (Bigger the gap, bigger the speed)

The AMC is doing it without kinematic relation in opposition to FLYpt which seems to do those calculations according to the synchronized kinematic math formula which could bring more accurate result.

From what you said guys, I conclude that one is faster and the other more accurate. I was hoping we could get both, an almost real-time super accurate motion.

EDIT:
I was thinking, maybe foolishly, that the AMC sensor info (current arm position) could be sent to Flypt for speed correction. But as @Thanos said that it accepts only target positions, it’s seems complicated or impossible.

Thanks again for your time.

I think someone as curious as yourself would find reading up on how PID controllers work a very interesting read.

The sole reason of PID control of a motor for our purpose is to make it reach the target or set-point as quickly as possible without overshooting. However each motor (actuator) is treated individually without reference to other motors position or speed. But all information needed to make necessary adjustments to sync them is available at the microcontroller level regardless of "kinematic relations" and would most likely involve slowing down actuators that have less distance to travel in relation to the one(s) with the most so theoretically they all reach their set-points at the same time when PID control alone doesn't do the trick.

This is pretty easy to accomplish on a 2-3dof but since I haven't built a 6dof yet I haven't tried scaling it to that level.

Oh Dear,
Imagine the scenario of rotary 6-dof, where to maintain a constant speed of let's say heave dof, the lever arm has to go much faster at the extremities than around its middle position.

In the case, where you make a transition from an extreme pose to another, (ex. full negative surge to full positive surge) when the controller receives the next pose and sends the arms full speed (without kinematic calculations) your platform starts to swim.

Actually more you increase the speed les linear your surge looks like.
It is not noticeable at low speed.

I dont know if @pmvcda is completely eradicating the "swimming phenomenon" I was just curious if it could correct my issue with @Thanos board by adding the speed correction.

You see the issue now?

As mentioned above I was considering a motor to mean an actuator and with a 2-3dof so I wasn't considering rotary. And I didn't mention I'm considering a balanced platform also.

But keeping in mind this is a simplified example there's an easy way to adjust the PID settings to fix the issues when using rotary for heaving and surge as in your examples. Since you need more speed +/- of middle position just increase P proportionally in the code when moving away from middle. Of course this doesn't account for weight redistribution and such but those could also be considered in making a more complex PID controller. Maybe more accurate would be to call this one a PpID controller or something like that.

I understand what you mean.
(I'm going to repeat myself, but for those who doesn't understand what we are speaking)
What I have done with speed, was because I can't have the 6 actuators in one board.
To adjust speed between 6 motors, you need to have info from the 6.
It's preferable to have speed control on the board instead of the PC. That's why I got an STM32F4. Just to try that.
As I said before, only advantage to have PID on the PC is to have a easy way of tuning it, because I can make it real time.
In my build, there's no "PID adjustment".
P, I and D have fixed parameters specified by the user in the interface.
What is adjusted is speed and that adjustment depends on PID parameters.
It works pretty good in my opinion. We could adjust parameters, depending on travel, load, .... but it's an unnecessary load for the calculation, at least on my build.

What I have right now, doesn't make that rotary compensation.
And it's almost impossible to do it real time. I think you need inverse kinematics for that, and it would not compensate to use it.
It depends on relative position of top joint and rod/crank joint.
But I think for our kind of application, it's not necessary.

There's a way to solve this.
Imagine you want to make a displacement between two far apart positions.
If you jump right away from the start to the end. without speed adjustment, you get the nearest actuator to reach destination first and last the one further.
With speed adjustment it's "soft" for linear actuators, but "oscillating" for rotary actuators, but they reach destination at the same time.
The rotating actuator produces speed variations dependent on angle and top joint position. That's what originates the oscillation.
But if you split that translation in 100 steps, you don't notice that oscillation. More steps, less oscillation.
What I mean is calculate intermediate positions of the top joint, not intermediate positions of the rod/crank joint rotation.
So to solve it the idea would be to calculate the intermediate positions and pass by all of them to reach destination.

But for our application, we are constantly receiving position updates, mostly small, some big.
The small ones you might reach the position, but the large ones, you never reach them, because motors can't follow that update speed.
When using the interface with the sliders, we move the slider and stop at a certain position. But that doesn't happen while playing a game. It's always moving.
In practise we are already making those 100 steps.

When speaking of load distribution, in my case it's automatically adjusted, because I increase speed if actuator lags behind (if I increase speed, I also increase torque).
He might lag behind, because of load or because the controller is not so good, but the idea is that he recovers the position by increasing it's speed in the next update.

This is my point of view right now, from what I feel on my rig.
I think one of the most important features we should always have in mind is lag.
We want to make it the fastest possible. So for me inverse kinematics to compensate that oscillation is completely out of the park.
Made some work on that years ago.
Was working on IPQ, the Portuguese Institute for Quality, in the metrology length laboratory.
I was studying the use of hexapods to calibrate measuring patterns. So we where looking for high high high precision.
To much calculus for our simple games.

Took this picture from one of my videos:

In blue, actuator position (real one)
In black the position we wanted
In red the calculated speed
You can see that the actuator is unable to reach the asked destination, and there's always some lag.
Oh, in grey is the calculated position, but I was using a low pass filter on the actuator, because with so much variation, the red led on the controller was always on. To many changes of direction and to fast.
Something I learn in Engineering, is that real world is not a basic math world. There's always something more interfering.
You can go near and near, but the cost of math would increase exponentially.
So calculating ultra precise motion cues and all that and in the end we forget the mechanical/electrical part of the equation.
All this is interfering in my next update, and I'm struggling with the auto calibration, (but also some other minor things) where those peaks should be ignored.
Most of the out of range alerts we receive in the interface are of positions we never get near mechanically due to the lag we have in the motors...
We have to look at the big picture, not only a small detail.

Note:
That position feedback for the interface could be good to calculate motion cueing. But since most people don't have that feedback, I'm completely ignoring it for now.
It's already hard as it is.

Thank you very much for your comprehensive explanation.

That brigs us “on the same page”

Back to the topic “center of rotation”.

Once you want to correct the center of rotation from “between the pilot seats” to the “captain seat”, you can move the kinematic center of rotation to the right. Yes, but, if you use the “mix sway on roll” feature you automatically get a false cue based on the shifted center of rotation.

So what you make better on one side you destroy on the other one. Right?

Although Austin does not want to add the lateral “approximation” arguing that it is ment for dual seat platforms, he was generous to provide the code for his longitudinal approximation, saying that if we want, we could find the logic inside and readapt it for the lateral as well.

I don’t know if something crossover could be developed but already making it possible for xplane would be a big step forward in my opinion.

I PM the code for you so you can have a precise overview how it is done.

Thank you.

In relation to what I wrote above, I could even be satisfied of something hard coded in the plugin somewhere in between the difference from Cessna to Boeing. I don’t know exactly now how much it should be. Maybe 500mm would be coherent.

It’s of course not ideal but as a stating point for testing, It would be enough I think.

It would be fantastic if you could bite into this problematic.

Best

@pmvcda aka FlyPT

Please prioritize your time to work on things as follows:

1. Put yourself first and do what you wish/need to do to keep yourself happy and motivated.

2. I haven't asked the community but I believe they would prioritize additional plugins, speed and rpm support for wind simulation, and code enhancements and fixes as needed.

3. Everything else. e.g. "ultra precise motion cues and all that"

And thank you again for sharing your "ride", "trip", or whatever you want to call it with the rest of us. Its really exciting for simulator nerds like myself.

Hi @pmvcda , do you think this would work on my p6 from dofreality?

Could we try?

Would it be possible to implement in flypt a select box with presets so you can save different filters, gains and axis flip status under the name of user choice?

Now it’s pain in the ass to reconfigure everything and loose settings while changing the game.

Thanks - Best