FlyPT Mover 3.5.3

I have a question I hope someone can help me with please. I have setup a hexapod with 18bits output. I am using Odrives and with the latest firmware the position is now defined in turns not encoder steps. A factor of 8192 difference. So I now have a range of 45 turns rather than 376,832 steps. Is it possible to configure FLYPT so that the range is defined in turns? I would appreciate any help. Thanks.

Sorry, I'm a bit confused. What do you want to send to the board?
Turns defined by an integer value between 0 and 45?
A float/double vale between 0.0 and 45.0?

Now 45 turns instead of 376,832 steps ... Why would anyone want to use this firmware...

We spoke on Discord, I now see what he wants.
He want's to output a decimal value with rotation (in turns not º). Like 11.25 turns.
Fortunately, I have it already in the next build.
Besides sending bit values to the hardware, I also added the position in a float (4 bytes).
This allows him to use the position in mm.
If using a 5mm pitch he just needs to scale the actuator output to get turns instead of mm, by using GAIN(VALUE;0.2) in the actuators filter.

Thanks, I'll try that. I agree, this should best be addressed in the firmware, trying to make a curve that matches the speed of the motors is not optimal. But I think some improvement is possible. I think Dof Reality uses SMC3 for arduino, but without their sources and configuration, I would have to pretty much start from scratch I think. So I'd rather spend time on making a good filter.

Detail is not an option on DOF Reality anyway, there is so much slack in the gearing that you can't really use it to create bumps etc. As a flight simmer, this doesn't bother me much. Nearly all movements are pretty smooth.

I use a shaker for engine and ground vibrations. I was able to create some really good effects with your transducer settings, I like them even better than what simshaker does. For the engine I created a sine wave with a frequency and amplitude that changes with RPM, and then overlaid that with a 12Hz frequency sine with high noise that gets more amplitude according to torque. It creates an irregular beat and one can feel the engine work harder when you give it more throttle.

For ground effects, I used a triangle wave at around 50Hz with some noise that varies with speed. I overlaid that with a triangle from an amplified signal from a high pass on the front left suspension signal, which gives me a low frequency bump every so often depending on the surface and the speed. Also works well, grass is more bumpy than tarmac!

One problem that I had, is that at one point, all the amplitudes were maxed out for no apparent reason. Neigbours probably didn't like that! I will have to investigate further what went wrong there. Maybe an Alpa "feature".

Oh good, first feedback on transducers.
Thanks.
Would be great if you could share the settings. I want to add some defaults on that window.

There's still some problems with that module, and I did not used it yet. I still have to mount the shakers in the rig.
Used it just for testing with the shakers laying in the ground and jumping everywhere

In the next build:


We can set custom hooks.
So users can update the values in the source, and share the souce file.
Now I don't need to update Mover just to update the hooks in a game.
Yes, I know, everyone can see them and copy them. But I hope we get some sharing here

Mover 3.3.4 ALPHA

Download in first post.

See post above with new source for custom hooks.

Now outputs position of actuators in mm or º besides bit value:
<B...> Bit value
<P...> Position value
<S...> Speed bit value (WIP)

Corrected some errors in the rig "Pose" and added 3d representation:


Some other bugs solved

This window everytime show at launch FlyPT. What's wrong???

Open the setup, correct it and save again.
It's because of the updates.
Some fieldhas changed and is making this error, probably a debug field

You suppose the error comes from opening an old, incongruent setting? However, with a new Mover version I never risk to import old settings, but add new module windows and copy values from screenshots. And since 3.3.3 I have the same message as deadlymanager ─ but I just ignore it.

But I still (in 3.3.4) have the same situation I described earlier (https://www.xsimulator.net/community/threads/flypt-mover.13464/page-83#post-208242) with only negative "original" values making an effect to OUTPUT module. I attach my new settings of v3.3.4. I'm sure you have an answer for that "dummy problem"!

Ok, first problem is simple.
I'm updating a value in a field, when the field range does not allow the value.
It's the maximum speed. I have to get first the speed bit from the file, to update the range allowed in maximum speed.

Second problem, you are using pose speeds <S...>. Is it what you want? Because it's not ready to use speed for now.
You need to use position <P...> (º or mm) or bit position <B...>

Speed is the only key that works in my current setup. And moving the sliders in RIG::JUST POSE translates absolutely perfect in smooth movement of my physical rig (but each axis in only one direction and back to middle).
I probably haven't understood the naming conventions we use in RIGs "Pose Key" and "Speed Key" fields. Sorry for asking three questions:
a) In the popup explanation for "Speed Key" you say the name should be "unique" ─ meaning they should NOT be identical to the <keys> used in the Output string?
b) When you warn about keys already "in use", we should NOT use them in the Output string?

c) what's the purpose of the new fields "Receive from port" in OUTPUT::UDP ?

hello!
i gave a try on 3.3.4 and noticed a few things.
first, in output::Thanos, the output string does not take into account new BPS values
they should now be " <255><255><BAxis1a><BAxis2a><BAxis3a><BAxis4a><BAxis5a><BAxis6a><0><0><0><0><10><13> " ...depending on your rig actuators order of course.
Second, when I add or remove poses while rig is online, it slowly moves to very strange extreme positions. I think it appends since Version 3, but not sure...
And.. that's all, All the work done is working incredibely well. I'm really impressed !

Ah, and yes, I would love to have the option to link rig gain to an analog value between min/max caped values.
I guess it would need a highly filtered input to prevent strange or bumpy behaviour, but i can deal with this.
if it's not too long to add, I think it worths the try.
many thanks !

Hi

I have some problems with the understanding and configuration of the AMC-AASD15A controller.

My rig configuration looks like this:

I have connected AMC-AASD15A channel 1 to the motor "actuator 1" as shown in the grafic.

I could manually config the actuators. Then it looks like this:

Then the movement of the rig seems to be correct.

But if I select "RIG :: LINEAR HEXAPOD" at the rig option, it looks like this:

The actuators are in wrong order

Is this a bug or is the connection to the AMC-AASD15A in this order as shown in the last pic above?

kind regards
Peer

The new fields in the output are not 100% yet.
They are meant to have feedback from the rig
In the future, you can specify an input string and update values with the value received from the rig.
It will allow calculation of PID in Mover.
We receive current position of the actuator from the rig, and knowing the desired position, we can calculate the speed we want on the actuator. That speed depends on the PID values inserted in the fields.
For UDP communication, we need to set the port where we are listening for data.

Currently, the calculated speed is always relative to the middle of the actuator, since feedback is not working yet. We don't know where we have the actuator without feedback.
Also the speed is sent as a "bit" value. This means there's no negative values.
If I use a 8bit value for speed, it means speed is between 0 and 255.
So from 127 to 0 is negative values and from 128 to 255 it's positive ones.
This should be handles by the controller.
I will also add an output in m/s, and this one is going to have negative values.
It's just like position of the actuator.
This is why you don't have negative values.
Don't use speed for now.

The pose rig is a bit different from others.
The output instead of an actuator position is a DOF position. Or better, the actuators are DOF's.
The problem you are seeing is that by default I also output the rig pose and I use the same key.
Keys are a way to identify the value you want to use, and when it repeats, you get that message.
So if you set that key, only the first occurrence of that key is identified, the repeated ones are ignored.
I allow the definition of some keys, not all. And that might be my error.
Sometimes to much freedom ends in some strange issues.
I have to rethink it, but for now, I'm going to change some of the default keys to solve it.

Those BSway, BYaw, .... are repeated (B means bit value).
If you go to the rig window, you can change the pose output here:

or the "actuators" here:

That way they don't match. I will change it in the next build, to have different names by default.
Problem is I'm appending B P or S on the actuators output, depending on the desired value.
To set each key, I would need 3 fields for each actuator, or even 4 when I get speed in m/s. It would be to much.

It's not a bug.
It's a mess

When I started making the rig, I always followed the order:
Actuator #1 first one on the front/right
Next actuators in clock order.
This is what you see in Mover images.

Thanos follows a different order. It's clock order, but #1 is the first on the rear left(not 100% sure right now).
So what I have done is keep my order.
But in the output of Thanos, I reorder the actuators to the order used by Thanos.
In reality, if you connect the actuators to the controller in Mover order, you have to keep it in the hardware also. That's why if you set it to 1 2 3 4 ... it works, because that's how you connected them in the controller.
But in the Thanos discord and manuals he says to connect it in a different order.
I would recomend to use Thanos order in the "hardware" connection, when using the Thanos output.
For hexapods there's no difference, but in rigs with traction loss, he uses a specific order with internal spike filters acting on the actuators.

Resuming:
-In the controller, connect the actuators to the plugs in the order recommended by Thanos.
-In Mover use the Thanos output, select the rig and keep that order.

Sometimes we try to simplify and in the end we make it complicated.
Idea here is: Don't think to much...

Sorry, not understanding it 100%
In the rig you can set gain:


And you can go to options and set a keyboard key or joystick button to change the value (changes in all rigs used):


This allows you to do it manually.
Maybe you are speaking of the auto gain. To add a minimum/maximum value?

Oh, I have to look at those.
That's why some people are having problems with the output.
Good catch on the keys
Thanks