FlyPT Mover

@pmvcda
If we could use "simtools dof order" it would be MUUUCH less confusing.

@benmax ,With yaw “world oriented” if like @yobuddy says, it outputs the +\- 180 deg. format you should have no problem to apply it to your platform.

The only thing is to apply a HighPass filter. (Return to center)
Inside simtools its possible to combine it with smoothing.
To achieve this combination in flypt hexapod or mover, choose a bandpass or even better the “EMA LP (EMA LP(EMA HP))”

I believe the first value will concern the “amount” of smoothing (LowPass weighting factor) and the second one the speed or persistence of centering (HighPass weighting factor)

Yes and no. Just as you describe, but in a full sim cockpit with real switches etc. Just need to be able to see my hands so it feels more natural and immersive.

I have just decided to reverse my position from yesterday, and with a slightly different way of doing things I think I can use the SteamVR "roomview" feature to see my hands. It won't be perfect but my tests over the last hour convinced me it will do.

The only problem now is I can't get the roomview feature to work if OpenVR Input Emulator is installed, and I can't fly the sim without that. Hopefully that will get fixed.

@Trip Rodriguez
Great idea to do it that way.
FYI I have RiftS, and it has the new Guardian Passthrough mode. There is a setting that when you exceed the guardian virtual wall, the passthrough camera turns on. There may be a way you can do that with your gear so when you stretch out a certain distance from your head, the cockpit turns semi transparent?
I cant find a rift video of it, but here's the quest example:

I'm not rushing you, but If you like a more direct dialog with actual owners of 4DOF platform, here is an invitation to my Discord channel: https://discord.gg/bx4PxYR

If not using same handle (pmvcda) let me now which to add you to the private beta group.


Thanks
Thanos

Hi,

I found the problem, not fully solved.
Had some unexpected personal problems.
Nothing bad, but they needed my attention.
Maybe in 2 hours I get home and pick where I left.
I will register in discord also.

I will be using FlyPT

You hit the nail on the head @Psionic001 !

I suppose I'll start with the 'problem' and work backward from there. Right now I feel like I've got a very acceptable way of using the guardian camera feature to interact with my cockpits, there is just one big problem that I know of. When I install "OpenVR Input Emulator", it causes the SteamVR camera features to not work.

I tested repeatedly, install OVRIE and the camera won't work, pull the OVRIE folder out of the SteamVR drivers folder and it's fixed. The main reason this is concerning is that I might be the only person this is a problem for, so there might not be adequate motivation for someone with the know-how to fix it. =(

Now to rewind and tell you about my experiments and solution.

When I originally decided that I might be able to use the HMD cameras to solve this problem, I was thinking what you likely are: Set the boundaries, and when I lean forward the camera comes in and I can see my real hands and my real panels. I figured that would be an ok solution. Well, turns out that the HMD camera video quality is bad enough to make that rather unpleasant. So, I gave up that idea and went to the Leap Motion.

When I tested the Leap Motion.. or rather when I finally got it working after many many hours of fighting with the driver/plugin for SteamVR I found that it was not a good solution. It was just too sloppy and inconsistent when I put my hands up to the panels. It works great out in midair, but not when I'm trying to interact with a real panel. Second, the software is a real PITA. In order to get it to work, every time I launch DCS World I have to hold my hands out in the air in front of me for the entire loading time. That gets old fast.

Then I had a thought, and I went back to the HMD Cameras.

If I use the full color translucent mode of room viewer, and illuminate my hands but have the rest of my surroundings as dark as possible I can have my hands visible but otherwise see the entire VR environment clearly.

Next problem, looking at my hands with the HMD camera, the panel scale is essentially off by a bit. I built it using the Vive wands to measure everthing out so it matched up, but the HMD cameras don't match up with the VR environment nearly so perfectly. Fortunately I don't have any of my cockpits all built yet, so I'm going to start fresh and work with the HMD cameras from the start to match everything up. That's actually beneficial anyway, because for this setup I want blank, non-gloss, featureless panels with just the knobs and switches in the right locations. This way there's nothing there in the real world (except my hands and the switches themselves) reflecting light and showing in my HMD.

The one other glitch, which I decided was something I can live with is that moving my head around significantly will change the angle of the HMD cameras at a different rate than it changes my view. The cameras are a bit forward from my VR eyes, and also farther out to the sides. Based on my experiments as long as I don't lean around an awful lot the error is small enough to pretty much ignore. I will determine the placement of each switch and knob while sitting in the cockpit in VR and using the on board cameras. This way each switch will be lined up with where my hands display on the cameras when I'm looking in that direction.

I'm also figuring on letting the switches and knobs reflect enough light that they are kinda visible on the camera, superimposed on their VR counterpart.

My experiments all worked out, soon I'll start building some panels and really give it a test. But there's that one SERIOUS problem of not being able to use the cameras and motion compensation at the same time. If that doesn't get fixed, this will all be a massive wasted effort.

As far as building the panels, it should be quick and cheap. I've got a large supply of switches and knobs and such, and totally plain, blank panels will be a cinch to make compared to the work I'd done previously on some cockpit panels that I wanted to look pretty.

I've got a dilemma as far as what to build first. I had kinda committed to doing the Huey (I love flying that module) and I have a real salvage Huey collective that I converted for PC use so in that regard I'm heavily invested. Of course, I could probably sell that for a hefty profit after all the work I've done on it.

But I've been kinda thinking about making the Ka-50 my main helicotper. Main reason being that a lot of the missions for the Huey appear to require you to switch seats and do some of the co-pilot jobs. The one really cool thing about the Ka-50 is that it was designed for a single operator so it's more practical in that regard. The other thing is that now that I've gone back to full travel on my motion sim (thanks to all the amazing work these guys have done with filters) I would have to very drastically limit the travel on my motion sim to keep the overhead Huey panel from hitting the ceiling. I mean I'd probably have to limit it to 10% or something.

Eventually, I'll be having to relocate my simulator to my own home (currently it's in my 92 y/o father's basement, about 20 minutes drive from my own home but I unofficially basically live at his house anyway to help him out with the housekeeping, cooking, and keeping him company so I don't plan to relocate the simulator to my own house until he passes away. Hopefully not too soon then! I've got plans drawn up to convert my screen porch into the simulator room, and if my plans work out I will have far far more overhead clearance so I can build overhead panels without fear of impact!

Anyway, I want to build the Ka-50, Huey, P-51, and maybe F-86 and F-14 cockpits. I'm thinking about doing the Ka-50 first, strange a thought as it is, I think that's the most practical option. P-51 will definitely be the first fixed wing pit I do.

@Trip Rodriguez
Big effort going on there . I think you’re going to have to employ a contractor to help you develop some dedicated software which brings me to my next point.
I find that in VR I get constant drift from my centre view. I have a dedicated button on my Stick to recentre the view. You could build a software feature that works like an AR tracker that auto aligns your VR cockpit to special markets on your real cockpit so they always remain aligned. The same technology could be used for motion compensation too.

FlyPT Mover Version 1.4 Beta

New/solved:
- Corrected bug that didn't showed loop elapsed time in main window (Menu->Tools).
- Corrected bug in logistic filter (future post explaining all filters).
- Corrected and updated some code in the serial output (needs testing).


Known problems/alerts:
- There's no default setup for now.
- Missing tool tips and help texts.
- To much modules, and there's no scrollbar to access them in the main window.
- No Limits 2 as some data problems that I need to solve. Seems the transforms are not correct.
- Graphic viewer with some problems. Data is not always saved (selections), graphics could be more clear. Needs more work.
- 3D viewer keeps rig even when you removed the rig, causing a crash if it's used.
- Outputs to serial could report connection problems in a better way.
- Memory cleanup needed.
- Speed optimisation in early stages.
- Bugs everywhere. Please report them.
- Missing some announced features.
- Missing license text. I'm lazy, hate those things
- Forgot centre of rotation in the controls... (all code in, but no interface)


Download:
In the first post of the thread

Well, employing a contractor is certainly not an option on my budget! I've got to figure out how best to do it with what's available. As I said, I think my current solution will be good enough if we can just fix whatever it is that prevents the Index cameras "room view" from working when OVRIE is installed.

I was thinking the same thing about aligning the virtual cockpit to the real cockpit, but that's not a realistic goal for me unless I can capture the interest of folks with the right skills/resources to make it happen.

Now I'm doing battle with myself to keep from starting to play around with making the Ka-50 panels setup. I've got a ton of more important tasks on the sim, and even if I get the Ka-50 pit all set up I can't use it unless that bug gets fixed!

But I'm excited, so it's hard. =/

When we install new versions, is it safe to move the LastSetup.FlyPTMover across?

Yes for this build.

Am I dreaming ? backlash issues ... gone ? ;-)

New build to come out today!
The last one still with problems in the main loop.

Could you please switch to “simtools order” or add it as a feature?

It would be helpful if the simtools output sliders could match the Mover

OK.
In the next build. Trying to solve some problems with this one.

FlyPT Mover Version 1.5 Beta

New/solved:
- Cleaned old code in the main loop. It was making the main loop slower. Now we can achieve fast loops
- Corrected bug in filter for 4 actuators rig.
- Disabled gravity by default on sources.


Known problems/alerts:
- Worried with interface performance (user interface). Thread for loop calculation might need some more for updates to allow a better relation between threads.
- Missing soft start/transition/stop. BE CAREFUL!
- There's no default setup for now.
- Missing tool tips and help texts.
- To much modules, and there's no scrollbar to access them in the main window.
- No Limits 2 as some data problems that I need to solve. Seems the transforms are not correct.
- Graphic viewer with some problems. Data is not always saved (selections), graphics could be more clear. Needs more work.
- 3D viewer keeps rig even when you removed the rig, causing a crash if it's used.
- Outputs to serial could report connection problems in a better way.
- Memory cleanup needed.
- Speed optimisation in early stages.
- Bugs everywhere. Please report them.
- Missing some announced features.
- Missing license text. I'm lazy, hate those things
- Forgot centre of rotation in the controls... (all code in, but no interface)


Download:
In the first post of the thread

I don’t know if it’s relevant, only to say that updating the sliders positions real time in HeXpod was a very consuming process resulting in jerky response.

I noticed also that adding a small delay to the 3D representation (5ms) has saved a huge amount of proc. ressources.

Kinematics and filtering has to be real-time but curiosly this doesn’t consume so much.

You could maybe try to add some delay to the sliders 3D and graph in order to speed up your gui.

Yes, I need to make it, but to add that delay I need to separate it in another thread.
For now, I wanted to solve jerkiness on the 4 actuators rigs.
The controllers are fast. They receive data at 2ms rate. So any slow down is noticed.