FlyPT Mover 3.5.3

Not until tomorrow evening, on the road right now...

@Avee I figured out what you mean, using a Pose: DoF From Value with longitudinal acceleration set to the Pitch DoF (filtered) does indeed work. Huge thanks for the tip.

However, that is a work around. In rig settings for a two actuator setup we should be able to set these there. Perhaps it should be a rig "5DoF with 2 actuators" It would be far easier to adjust motion from the pose from motion window rather than having four separate windows to deal with.

Again, thanks for the tip.

Everything is working great, but as mentioned I did have to create a lot more windows than (my opinion) I should have. I have three pose from motions created: Heave, Pitch and Roll, Surge and Sway. Mover Alpha is working great with iRacing.

Hi Flypt ,
Tested Mover 3.3.5 on my 6dof rig and everything ran well like 2.9.9 .
Not yet tested esp32 with my pneumatic actuator but connected thanos amc1280usb and your esp32 card and no comport errors ( running half an hour).
Thanks for your job

Greetings friends!

@pmvcda I'm trying to help J-1775 figure out his problem. The thing is I don't know anything about the numbers in the output string... not even a BIT! Bad-um-tsssh. That's total gibberish to me, so bear with me!

J says that his sim is only responding when he uses "speed" in the output string, but not when he puts "postion" in the output string as he should.

What I notice is that when "SSurge, SSway", etc. are used there are only 6 digits (two groups of three) being output for each DOF and the first group of three increase steadily without ever going back to a smaller number as you move the sliders to the right without any rolling over or whatever you want to call it.

When "PSurge, PSway", etc. are used the output string contains 12 digits (four groups of three) being output for each DOF and all four of the groups are changing erratically rather than a nice gradual increase like the speed output string.

I basically have no idea what any of this means, but I would have thought that since both speed and position are supposed to be putting out 16 bit values the number of digits in the output strings would be the same between them, even if the range of values are different.

At any rate, I understand that J needs to be using "position" output rather than "speed" output, but I hope that the fact that his sim sort of works with the six digit output from speed, but does not work at all with the twelve digit output from position can help someone more educated than myself figure out how to make Mover send numbers that his sim finds acceptable!

Trip

PS- On a personal note, life is still chaos and I still don't have a shop space to resume work on my own sim building project, but thoughts of it are in my head almost every minute of every day! My own garage isn't wired to handle a welder yet, and it's not a super easy fix as I have to run a new line to it from the main panel in the house either over or under a 20 foot wide area of the stone driveway. The current line is in an underground conduit that goes across it, but I doubt I'll be able to feed a beefy wire through it. In addition, there's no space in the garage to work unless I put one of my poor Corvair Corsa's out in the weather, so I need a place to put one of them where it won't be damaged by the elements to make floor space. I have several possibilities in mind, but none of them are going to happen for at least a couple more months yet. D= In the meantime, I've been working the past two days to create a shop space for my 3D printer and my K40 laser by sacrificing my screen porch to the cause, so I'll be able to make some progress on cockpit panels etc. at least....

@Historiker , no problem at all.

Can you show me the SimTools mixing you are using on the rig?

I never had a 2DOF rig, and the idea I have for the "conventional" 2DOF rig, is that you have only two 2DOF, in this case just roll and pitch.

Other dof's are locked in the rig, because they don't exist in the rig, and that could cause problems on motion compensation, 3D previews....

Now, in the pose from motion, you are able to use roll , pitch, surge and sway, with the mixing.
That is the correct way to do it in Mover.
Your problem is with heave.
That's a "fake" cue, and can't be added in the motion cueing alghorithm.
So like @Avee says, you need to add a pose: "DOF from value"

Then add it to the rig module

There's no other way to do it and to keep the use of VR compensation.
Using directs, works just like SimTools, and you loose the pose info.

I know, to much windows. Maybe I could replace that module with one where you can add multiple effects.
I think I will do it.

What a mess...

Ok, in the last build, and the one before, in my stupidity, I though I could add some letters to the key names to make it easier to understand what they mean.
Making it, I broken setups and introduced some bugs (in directs at least).

So, what I have done is to add a B to the key, like <BAxis1a> that means the value is in bits.
<PAxis1a> means the value is the real value like mm or º, in a float that uses 4 bytes.

So we should have <PSway> , <BSway> for position.
<SSway> is speed and in bits, should be <BSSway>, I'm considering to add speed in value also and it would be <PSSway>

Ok, like you see this is stupid...
Ideal was to allow the user to set all the keys. But they are to much.
So I'm going to try to clean up all that mess. Would like to keep something with consistency, and even considered using a different marker. Instead of <...> I could use {...} or [...], but they are already used in some strings and they make the code run slower.
Ideal is to append the name, and those letters still look the best. But it's a change that people might not understand easily.

Now that I told this, when he's using PSway, or PSurge, each value uses 4 bytes, and he needs to convert them into floats when he receives the data, to have them in mm or º.

The speed is bits, and depends on the selection he does on the rig. If he's using 16 bits, each value uses 2 bytes. If you say he has 3 bytes, he's using more than that.

I can see it with him.

On a side note, yes, life makes those things.
Years ago I considered buying a small shed to put the rig inside.
Even today, I think it could have been cool to do it.

THANKS Trip and pmvcda! I'll do some more tests with that in mind and report back.

If I have Oculus Rift old version , Can I use this ?
I would like to learn more on this program for platforms where motion compensation works in virtual reality.
Thanks

Hi,
Yes you can!
And it's working great!
Just follow instructions on https://ovrmc.dschadu.de/en/vt_flyptmover
Dued to new naming convention for keys, use PPsway... in output :: mmf

Hello,
I discovered FlyPT this weekend and it's a great tool.
Also I wanted to know if there was a way to know the maximum value of the angles or displacement reached before being out of limit reached we manually move the cursors?
see picture:


Thanks

It depends on the combination of angles.
If you have 10º in pitch, the limits for all the other dof's change.
This is specially the case of hexapods.
What you can see, is witch actuator got out of range in the 3D view.

EDIT:

Here's a figure showing the limits of a hexapod.
Just translations...

You're Right, It depend on the combination of angles.
So if i don't change the others , i would have liked to know the max position reached.
To do this, I move the cursor and look again when the limit is reached to then note the value.

Hi fanch64
Can you please explane a bit more about "naming convention" of the Virtual Tracker?
Maybe with a screenshot?

I´ve testet it with "<PoseSway><PoseSurge><PoseHeave><PoseYaw><PoseRoll><PosePitch>" and it looks ok for me.

Thanks in advance
Peer

if it ain't broke, don't fix it!

ok, with versions prior 3.3.4 Pose keys for rig were named PoseSway...
now, default name is PPoseSway...
if you imported a .Mover file created with an old version, naming is still the old way.
watever you name them, they have to be unique, and consistent between rig and output.
see on screenshot:

Hi @fanch64

Thanks a lot for clearing. Yes, I used a old config.

Maybe I should make a new config with the new version of Mover.

kind regards
Peer

Hi FlyPT

It sounds really interesting.

Do you have something special in mind for transducer with Arduino?
Any link or more information?

I got the idea to use the arduino which makes my "wind" to use it also for the transducer.

Thanks in advance
Peer

You can drive a audio transducer from the Arduino, think it's possible, instead of an audio board.
Or use a small motor with an weight offset a rotate it at different speeds to make vibration. Just like PS4 controls, or Fanatec pedals.


A good example here:

Yes, but that "easy of use" is now a bit complicated.
I think I can make it better, specially with the customisable curves, but they don't work yet.
But yes, some of those sliders used in SimHub, might come to Mover also.