Meet YAME: Yet Another Motion Engine

Thanks

yeah, it appears the only difference in the pro version is the amount of planes.

I have added (very basic!) support for Condor2

Angular rates are available natively in Condor2. That's a good thing, for sure. Accelerations are afaict world referenced, but I am hopeful that the proper accelerations (vehicle referenced with gravity) can be calculated from them.

There's still one thing that puzzles me though: Sometimes the export interface gives me "pitch=NAN" at very high pitch values (+/-85°). NAN stands for "Not A Number" and is often used to indicate/prevent a division by zero. However, the quaternions in the export interface appear to be unaffected, so there might be a workaround there...

All this took surprisingly long, because with 6 different sims supported now, I had to check every change I made against all the other sims and I had to add a "Source Select" window that lets users choose their source so that YAME knows what data to expect. Unfortunately YAME does not remember (yet) which setting the user last used or which would be most suitable for the vehicle profile, so the user will have to actively select it everytime for now. Hope to change that soon... [Edit: Done!]

It also conveniently patches and unpatches Condor2 as well as all the other sims. Patching iRacing is not fully supported yet. Still some troubleshooting to do there.

The software should self-upgrade on next start

Cheers,....

Hi Frank,

thanks a lot for adding it! Cant wait to test it out at your place!

You interface the motors with USB-RS485 Adaptors and the like. Thanks

OK,... that seems quite straight forward

I can talk to a COM port, but what do they want to hear? How would I tell them to go to 50% extension for example. Are there any resources online about the communication protocol?

@Dirty ,

Hi, if you have the courage, here's some info on the protocol and how to do it:
https://www.yumpu.com/en/document/read/41629079/tmbscom-enpdf-servo2go

I wanted to add it, but without hardware to test it's not easy.

Thanks, I will look into it. If YOU think it takes courage, it really means something

I had the same problem with the Odrives. Eventually @PeterW lent me one and then it all became clear.

So,... if someone has a spare SCN5/6 lying around...

there are converter for that
https://www.tme.eu/de/details/da-70...IX9UQ4LcmegBfjZSbCXhLw6AKx6iGTGxoCUgIQAvD_BwE

@Dirty do you have any plans to add a VR virtual tracker for OVRMC/OXRMC?

Hmmm,...

well,....

kinda,...

sorta,...

...not yet. ...YET!

But I have thought about it. I read on the OVRMC discord about a year ago that it uses a MMF and I saw a template that didn't look too complicated. I would sure like to,.... but with me not using a virtual tracker and with a userbase well within the single digits I have just not had the urge yet to do it just for the fun of it. Then again, with most people using a virtual tracker, how would that userbase ever grow

Reminds me of the "empty-dancefloor-problem" in economics:
Empty dancefloor --> No-one's gonna wanna dance
No-one's gonna wanna dance --> Empty dancefloor

Long story short: I would love to, but won't find the time for it for a few months at least.

Thanks for your reply. I know I'd start using YAME a lot more when you do add it! I'm sure a lot of others would as well

-Adam

I feared you‘d say that :-D

I put it on the To-Do list and chances are you‘re gonna see me ask a couple of unbelievably stupid questions over on the OVRMC Discord some time soon

Hi @Dirty , will YAME work with Denis' rig using M4S and rotating actuators?

Cheers,
DK

Hey @DerKlausi, (German?)
So far, I don't support rotating actuators (yet). I have the math done for it, but since I don't have a system to test it on, it is a bit difficult to bring it to a point where I could have others test it with a clear conscience. And I don't want to implement something half baked to then ask the users to essentially be my Guinea pigs.

There are two options floating in my head:
1. Output the raw DOF data to the M4S controller and let it do all the inverse kinematics. From what I hear, some are using that feature and it seems to be well tested.
2. Adding the feature natively (as far as I can without the ability to test it myself) and then rely on feedback to make it safe and usable.

Both are actually not that hard to implement. What would take up most of the time is modifying the 3D view to correctly depict the cranks and rods of the rig.

I guess as a first step I could try option 1 and see how people get along with it. If you own a crank-arm rig and you're willing to do some testing and do a little bit of back'n forth messaging I could give you an experimental build... and if you tell me that you live in the Lake of Constance (Bodensee) region of Germany I will show up on your doorstep with a labtop and enough pizza to have it done before the sun rises!