Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A more accurate way to convert radians to degrees in HeliosExport16.lua #789

Closed
Shaftoe62 opened this issue Jan 11, 2024 · 7 comments
Closed
Assignees
Labels
Delivered Code for this issue is in a generally available Helios Release enhancement New feature or request

Comments

@Shaftoe62
Copy link

Shaftoe62 commented Jan 11, 2024

I found this section in the helios_private.processSimulatorData function in HeliosExport16.lua:

helios.send("T1", math.floor(0.5 + pitch * 57.3), "%d")
helios.send("T2", math.floor(0.5 + bank * 57.3), "%d")
helios.send("T3", math.floor(0.5 + yaw * 57.3), "%d")

That is a very inaccurate method and also kills all the precision for these values.

Lua has a build in function to convert radians to degrees. For example:

helios.send("T3", math.floor(0.5 + math.deg(yaw)), "%d")

Alternatively you can use 180/math.pi as a multiplication factor in stead of 57.3:

helios.send("T3", math.floor(0.5 + yaw * 180/math.pi), "%d")

And the way the value is rounded, by first adding 0.5 and then flooring it, introduces a significant inaccuracy.

I know it's frustrating that there is no proper math.round function in Lua (as in many other scripting languages).

But, formatting a value to text (with the desired precision) and then converting it back to a number does that a whole lot better and much more precise than to first add 0.5 and then flooring it:

helios.send("T3", tonumber(string.format("%.2f",math.deg(yaw)))

That's how I would do it. That would result in an accurate yaw (geographical heading) in degrees with a precision of two decimals.

@BlueFinBima
Copy link

@Shaftoe62 There is always a trade-off between precision and performance, and the current implementation sought to achieve a sensible compromise. Calls to the math library are expensive. Can you explain what real-world impact this reduced precision has on your profile.

@Shaftoe62
Copy link
Author

@BlueFinBima

Well, currently degrees are returned as whole degrees, while over a longer distance that is very inprecise and can make you miss your intended location by miles. So, even if decimals are not displayed in most cases they do play an important role in DCS if you give a "Turn on me" command to George AI in the AH-64D.

As for calls to the math library being expensive; you could make only one call to store math.pi in a variable and use that like this for example for all the radians to degrees conversions:

local pi = math.pi

helios.send("T3", tonumber(string.format("%.2f",yaw * 180/pi))

@BlueFinBima
Copy link

Thanks. I do know "how" to achieve greater precision (but thanks for your thoughts), however I'm still trying to understand "why" greater precision is actually necessary in reality (as opposed to theoretically). Are you attempting to create some form of auto pilot / remote control?
A more philosophical question is "Why should Helios Virtual Cockpit enable a user to fly with greater accuracy / control than a human can achieve?"

@Shaftoe62
Copy link
Author

If you "fly" the AH-64D as the CPG you can use George AI to do the actual flying. In different ways.

When you look at a specific direction you can give the AI the command "Turn On Me" when the AI is in either H-B or FLT mode by hitting "D" on the keyboard.

The exact heading you are looking at will then become the new course the AI will be flying towards.

And although the feedback the simulator provides through the DCS interface when you give the "Turn On Me" command is all in rounded degrees, internally it works with a much higher precision (I believe).

You can see that very clearly when you read out the telemetry with a higher precision.

I think there is a way to extract the exact commands given to the AI from the telemetry. When I get to that I will get back on this with (hopefully) real proof!

But in a way, yes, I'm improving on the precision on the AI commands and that effectively translates in a kind of "autopilot".

I have to figure out how to capture a video of how it all works together to illustrate it better I'm afraid.

@BlueFinBima BlueFinBima added the Fridge Valid feature requests which are low priority label Jan 24, 2024
@BlueFinBima
Copy link

The philosophical question remains. George isn't supposed to be an auto-pilot, it is supposed to be "human-like" and giving George a command with greater precision than humans would use to interact with other humans does need careful consideration in the context of Helios and DCS in MP.
At this time, I'm inclined to the view that Helios has an appropriate level of precision.

@Shaftoe62
Copy link
Author

Well, George AI was actually not the original reason why I wanted more precise degrees. That was actually the NOAA Nautical Compass Rose as is implemented in the DCS map.

There the Magnetic Variance is shown with a precision of one decimal.

image

So to calculate that variance I needed both the geographic and magnetic yaw in a precision of (at least) one decimal.

And because I also made my own NOAA compass with the aircraft heading, wind direction and look direction as lines/arrows, I also needed that added precision.

Otherwise the arrows/needles would jump from one whole degree to the next. Which is very noticable on a compass that large and that annoyed me to no end.

image

This is actually always the case if you want to give any kind of dial an "analog" feel. Whether it is a compass, the standby attitude indicator, or whatever. You will always need at least a precision of one decimal. Preferably two.

Remeber this one? Same thing.

https://www.reddeadonlineclock.com/

BlueFinBima added a commit that referenced this issue Jan 24, 2024
@BlueFinBima BlueFinBima added enhancement New feature or request Awaiting Delivery Fixed and awaiting shipment in a new release and removed Fridge Valid feature requests which are low priority labels Jan 24, 2024
@BlueFinBima BlueFinBima self-assigned this Jan 24, 2024
@BlueFinBima BlueFinBima added Delivered Code for this issue is in a generally available Helios Release and removed Awaiting Delivery Fixed and awaiting shipment in a new release labels Jan 29, 2024
@BlueFinBima
Copy link

Shipped in 1.6.606

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Delivered Code for this issue is in a generally available Helios Release enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants