FlyPT Mover

Continuing on my previous question, after digging for a few minutes on Google, here is the post about RPM
https://forum.dcs.world/topic/224429-export-values-for-engine-informations/
So it seems I have to get the RPM value from the mainpanel_init.lua in a specific aircraft's folder.
I found this in the UH-1H folder

RotorTach = CreateGauge()
RotorTach.arg_number = 123
RotorTach.input = {0.0, 360.0}--{0.0, 300.0, 320.0, 339.0}
RotorTach.output = {0.0, 1.0}--{0.0, 0.83, 0.94, 1.0}
RotorTach.controller = controllers.RotorTach

GasProducerTach = CreateGauge()
GasProducerTach.arg_number = 119
GasProducerTach.input = {0.0, 50.0, 100.0, 109}
GasProducerTach.output = {0.0, 0.45, 0.91, 1.0}
GasProducerTach.controller = controllers.GasProduceTachRPM

Now I have no idea how to tie this information in the FlyPt's LUA script to get the RPM working.

I'm also assuming that if I'm lookingat a specific aircraft and will be tying RPM value to the "tach.arg" which would either be 123 or 119 in this example, this LUA script will only work for UH-1. I'd be ok with that, since I primarily fly only one aircraft, and worse case scenario I can switch between multipl lua scripts manually if needed.

I just need to better understand how to pull this RPM value into FlyPt, which has this...

local engine = LoGetEngineInfo()
--[[
RPM = {left, right},(%)
Temperature = { left, right}, (Celcium degrees)
HydraulicPressure = {left ,right},kg per square centimeter
FuelConsumption = {left ,right},kg per sec
fuel_internal -- fuel quantity internal tanks kg
fuel_external -- fuel quantity external tanks kg
]]--



Would really apreciate any coding help with this. I do not know LUA scripting, so please treat me like a 5 year old with your answers/suggestions, if any.

Thanks!


P.S.

Mucking around with this and trying to figure this out on my own....

--local engine = LoGetEngineInfo()

local MainPanel = GetDevice(0)

RPM = MainPanel:get_argument_value(119)

This doesn't do anything in FlyPt.
Un-commenting "local engine"doesn't do anything either.

having "local RPM = MainPanel:get_argument_value(119)" doesn't do anything.

Definitely need some help here.

So continuing to experiment with this, it seems RPM is just not a supported value in FlyPT for DCS at least.
I figured I may be able to hijack one of the values that I know I'm getting telemetry already, in the default configuration, something that I may not use for the helicopters.

I see Angle Of Attack is getting a live value, so I've substituted Gas Producer for the Angle of Attack in the .lua script.

Export.MainPanel:get_argument_value(119), -- 23 = Angle of attack

It seems to work and get me live value from DCS. Now the next complication is that it is not a clean zero to whatever value. At engine off, it seems to be somewhere around 1.32, as the rotors start to turn during a start-up, this value starts to oscillate, which is actually a good thing, since I can directly attach it to the Roll axis on the rig. However once it stabilizes at the full throttle, the value drops to around 1.2.
So now I have to figure out a mapping that would keep my rig at Roll = 0 when this value is at 1.3 at engine off and when it is at 1.2 when at full throttle...

However the effect is kind of nice, as it matches the rotation of the rotor that I can see above me 1 to 1, and as it slows or speeds up during slow rotations, I can feel that roll in the frame.

At this point I don't know if all this PITA is worth it, to be honest. I'm getting a brief body roll at the startup from just a regular Roll position, and I'm assuming that is exactly when the chassis actually moves from the rotation of the top rotor, all other times the mass of the chassis is too much for it to shake/roll. So this additional movent that I'm after may not even be present.

It may simply be easier to just get the secondary effects, via a transducer to get some additional vibration through the rig, rather than additional movement...




if anyone actually responds to this eventually, is there a way to attach a sign wave instead of a noise to a rig's pose value in FlyPT? I know there is a Loop Source that has a Sine in it, but there is no way to drive that Sine's amplitude with a telemetry value from a sim, at least I don't see a way to do it. It would be nice to have something similar to a noise where a value from telemetry can control the height and width of that sine wave, that way it can be a regular oscillation, rather than a random noise.

You could generate the sine wave in your lua script, I suppose ?

The formula for a sine wave is simple:

A * sin(2*pi*f*t + p)

where:
A is your amplitude, i.e. how much shaking you want
pi is 3.14
f is your frequency (i.e. what you call "width" of the sine wave) (I guess your RPM ?)
T is a value which is monotonically and linearly increasing with time.
p is the phase of the sine wave, which you either ignore (=0) or tune it to sync it with something else (with a value between 0 and 2*pi, where 0 is no phase shift, pi is 180° and 2*pi is 360° phase shift).

You can get the time (in seconds) in lua with:

socket.gettime()
​

I don't have DCS installed to test this unfortunately...

I had some time so I have made something which might work for you.
https://pastebin.com/QbKsySut

This will replace the "Stall" value with an sine wave which is coupled with the engine rpm.

The implementation is between lines 113 - 120.
The hijack of "stall" happens on line 150.

You will probably need to add some kind of random noise to this value in order to have a more realistic effect, depending on your preference.

Also, on line 115, there is a hardcoded value for "rotor_max_rpm" which is currently set to 324, which corresponds to the UH-1. This is needed because DCS does not actually return the RPM but returns a percentage of the RPM.

As with all changes, be careful when you use this as a wrong gain on this value can result in serious shaking ! I would advise to start with a gain of 0.01 then increase as you see fit. Try it with the rig OFF to verify visually on the interface how much motion this would create.

Edit: I have not tested this on my rig

Hey, thanks for the help.
I've been banging my head over your code for a few hours now.
Overall it does work, it produces a movement in the Stall value.


The movement however is not what is intended, unfortunately.

It seems to either be affected minimally by the RPM value, or not at all, essentially all I'm seeing is a constant and VERY fast oscillation somewhere between -1 and 1 and the frequency of that movement don't seem to be affected by the RPM increase or decrease via throttle, or at least very hard to see in FlyPT UI.

As soon as RPMs go above 0, it starts shaking at full blast, increasing RPM don't seem to decrease the frequency either.

I'm trying to see what the culprit could be potentially for this.

At first I thought it could be the timing/updates to the game from the LUA script, as it feels very random this oscillation and i thought that maybe it's grabbing the value from the LUA calculations but the timing is off so it is not producing a smooth sine curve, but I do see you using the "ts" variable which should be getting game time and using it in the formula, so not sure if that is the reason.

Still trying to work this out.

As part of the troubleshooting, I've plugged vibration_freq directly into the Stall, just to see what it is doing, and it is increasing/decreasing smoothly with the RPM/throttle, so all the calculations prior are working well and report stable values to FlyPT.

It looks like the vibration_val calculation is where it all breaks down.

P.S.
So to test, I've added an isolated sine generator just in the LUA script and attached it to the stall value.
The end result was a nice, smooth rocking motion with the period of 2000 milliseconds that I've set in Lua, so it is able to generate a smooth calculation using game's time stamp.
However, once I connected the RPM calculations to that sine generator to control it's frequency, it instantly broke, and I'm back to getting the noisy oscillations that don't seem to be affected by the actual RPM change, until close to zero where it just stops the oscillation altogether, abruptly.

Try reducing rotor_max_rpm to something your rig could handle.
Divide it by 2, then again by 2, etc. until you can feel the effect clearly. The speed of the oscillation should be proportional to the RPM.

The current settings mean 5.4Hz at max RPM, which is maybe too fast for your rig to handle at appropriate amplitudes (i.e. very low amplitudes), hence you not feeling anything.

Again, be careful with the gain. Start low and increase slowly.

If you find that this helps, you should run transducers for the higher frequencies in combination with the low-frequency motion.

Yeah... this is not hardware specific though, in FlyPt the values jump erratically without even connecting my my rig. With your suggestion of dropping max RPM value doesn't seem to do anything, the values still look like noise rather than a sine wave. They do oscillate between -1 and 1, but the oscillation is very jittery.

I was able to get closer to what I am looking for using just a very crude ifelse mapping. I've also converted it into millisecond for my own sake, as it is easier for me to work in time units rather than Hz.

local sinePeriod = 0
local amplitude = 1

if RPM_pct >= 0 and RPM_pct <= 0.001 then
sinePeriod = 0
amplitude = 0
elseif RPM_pct > 0.001 and RPM_pct <= 0.002 then
sinePeriod = 1000
amplitude = 0.25
elseif RPM_pct > 0.002 and RPM_pct <= 0.003 then
sinePeriod = 1000
amplitude = 0.5
elseif RPM_pct > 0.003 and RPM_pct <= 0.005 then
sinePeriod = 1000
amplitude = 0.75
elseif RPM_pct > 0.005 and RPM_pct <= 0.01 then
sinePeriod = 1000
amplitude = 1

*This mapping is not right and not clean, just a working example.....

This does produce a clean sine wave, however once it jumps from one RPM value to the next, there is a jump in sine wave as well so it is not smooth in transitioning from ifelse to the next.

I've tried doing this mapping with a linear relationship equation, but I'm running into the same problem, where the values start to jump and be very jittery, instead of a smooth increase/decrease in frequency and amplitude based on the RPM changes.

What I've also just figured out by doing this, is that the "engine.RPM.left" brings back the "Gas Producer" RPM value.

I'm trying to emulate the movement from the rotor spinning up, which should be coming from the Rotor RPM dial, since the rotation of the actual rotor and engine RPM do not match up as it spools up.

I have no idea what value that would be in LUA. I'm guessing this where it has to go back to bringing back the value from the cockpit panel, rather than the engine telemetry.


Thanks for all the help though, I'm at least getting a little bit more comfortable with the LUA, at least on the very basic level.

Hi @pmvcda!
Some months ago (nearly one year) I was testing wether the official Odrive firmware (from the Odrive robotics webpage) is running with your mover interface. For this test you have been so kind, to create a 3.6 beta-Version with some (mandatory) special-Odrive-features "Actuator filtering" and "Dislocation by turn".
My tests went absolutely great and succsessful, so a huuuuge thanks to the master .
From this time on, I am using this in my 6DOF without any problems!

I think, having this modifications would be a great benefit for all Odrive-users and those who want to be (because the use, reliability and documentation of the official Odrive firmware is IMO much better, than the firmware that is shared in this forum).

So my question is: could you pls make this special-Odrive-features accessible in this forum for other people and testing?
And will the special-Odrive-features also be included in a maybe future mover-version ??
Thanks a lot!
Wickie

@pmvcda I am working on a traction loss plateform but I found out that there is no appropriated way to get the traction loss output, am i right ?

If you add Pose -> Black Box Motion for cars, there is an option for Traction loss

hello I'm looking for a profile for f1 2023thx or has work on the flypt mover stopped? so there will be no new plugins?thx

@pmvcda
Example 2 - Arduino Uno controlling two fans with different speeds.
I did this exemple on ( the binard output string ) FlyPt mover page but with DC Motor to control Seatbelt .
the code does’nt seem to work correctly . Someone of you have this problem ?

Maybe because the fan code is for 8 bits and the seatbelt uses 16 bits in the actuators. Not sure right now...

Thanks for the quick response Pedro, even without the motors installed, my Cytron driver's dual output dimmer (MDD10 A) is telling me that when I activate (actuator slider) on one side (LFAN), there is a signal on my two outings, one stronger than the other. I think I will install two limit switches and an encoder on each of the motors. Same as Sim actuators to control the two seat belt motors.
Thanks!

@pmvcda Any chance you could integrate WitMotion WT901C support like SRS for Motion Compensation inside of Mover?

Hello @pmvcda
I suggest some essential features for performance rigs:
Acceleration and deceleration ramp, applicable to each DOF, and max actuators speed settable from the rig module because from the filters it's quite impossible to replicate the actuators and rigs, performances.

As far as I know, you can set up such ramps in the servo driver…(?)

Correct, you're right, but I can't set the acceleration ramp and deceleration ramp differently, moreover doing so the behavior of the rig in the mover will not be consistent with the real rig

If a max acceleration would be implemented as a sample based filter, it could also be useful for motion cueing.