FlyPT Mover

Hi @Avee, thanks for the heads up. I'd read about it but I thought it was only the saved profile(*.mover) on the server that were lost. If it's the main program that he is struggling to recover, I understand that it will be a lots of work for him. Hoping all the best for every great work that has been done and contributed to the communities.

@Avee and @khairul nizam ,

The problem is only on the shared setups, not on the code.
Code is all stored for all the released versions.
The server where I have the setups had a major update, and I lost the setups (still trying to recover them).

For code all is well. Working on the new release right now.
Had some problems in the last days but with a kidney (it will be solved soon).

@pmvcda

Just received my witmotion sensor yesterday, so if you need assistance with testing, I'd be happy to help.

Minor request for a future version.

As im often a bit lost on what rig gain i currently have and sometimes go into negative value this feature would be great. If its possible to add a potentionmeter to assign and control one or more rig gain from 0.1 to 1 that would be amazing.

You can assign buttons or an encoder to rig gain in Options

Appreciate the answer and i am aware. It is not however the feature i asked for

Hello, I need some advice, In the "OUTPUT :: Motion compensation for OVRMC" I need to have the rig's position after the actuators filtering. I'm using logistic filtering in "Actuator filtering" so that, when the actuators approach the limit, the speed slows down in order not to have a brusque stop but a smooth, amortized, stop but in the Motion Compensation I see the 6DOF positions bypassing the actuators filtering.
In theory, I would need to have the positions that I see in the "OUTPUT :: UDP" module but unfortunately from this module, there are the positions of the axes not of the 6DOF
Does anyone have a solution to my issue? Maybe there is another way to smooth the actuators' limit reaching to avoid MC problems?

Thank you

For that we need to have forward kinematics.
And Althought the code is already prepared to add it, the cpu load is high and for now I don't have a solution.

Resuming, we need to calculate the pose from the actuators position and it's easy on some basic rigs, but in hexapods there's many solutions and complex calculations that take to much time.
I tried going with iterations but it was not working and was also slow.
Some faster solutions exist, but we need to know some extra measures and for that we need more actuators....

So for now I recomend you to use filtering in the pose instead of actuators. Sorry.

The next release is also ready to add it and has some features intended for it, but I will look at it after the release.
There's many interesting things to do with forward kinematics.

Thanks a lot, Pedro, meanwhile I'm solving with the level of logistic filter in the actuators, like in the picture, where the final pose is much further than the actual physique limit, as you can see the actuators on the mover overcome much their stroke but are cropped by the logistic, this is a workaround solution. This way works quite well but the issue is the motion compensation with the virtual tracker, with a physics tracker I would solve but I can't use this solution.
Unfortunately, I can't filter the pose because when I reach more DOFs limit at the same time, for example, Pitch and heave, if I have already reached the limit of pitch and come a quick heave the actuator more extended get a brusque stop.


Thank you very much.

For the next release I have another solution.
We can choose 3 types of motion for the rig:



First one is a follow alghorithm. It follows the requested pose even if she's out of range. It might induce some false cues, but keeps track of the pose for motion compensation and the rig is always moving.
Second one stops moving the rig when she's out of range and when the rig goes back to range it transitions to the new valid pose. This avoids sudden movements on the rig and keeps track of the pose for motion compensation..
Third one is what we have right now, actuators move while there's range but if one goes out of range we loose track of the pose for motion compensation.

I think that using the first one might be the better solution



In the viewer, we can see the ghost showing the requested pose and the rig in the possible pose, following the requested one.

Yes right Pedro the first option looks the best. Thank you very much for all your efforts.

Good afternoon dear friend. Please tell me when can we see the new FLYPT? This year or only next year? Will it be paid or free for 3dof? I have assembled my installation and am very satisfied. dirt rally 2.0 works great. but unfortunately wrc ea sports can't work yet. I've tried other programs, but the platform only works well on FlyPT. I'm really looking forward to the release of the new version to finally play for fun in wrc 23.

Would a good solution for this be to add another pc for mover?

Hello Pedro, do you remember the Logistic 2 filter? That's what a great idea, that's worked only in the deceleration condition and not in acceleration. When I tried I was so enthusiastic but that's was need to be fixed to be usable,will this filter still included in the new release?

Yes

No, it will have to work on one PC or it would be a miserable code...

I will find a solution.
One I will try is to use the WITT sensor for rotations, that will help with the calculation of position because we reduce significantlly the number of soulutions and we are calculating just 3 variables (sway, surge and heave) instead of 6.

What we could also do, is to use something like 9 actuators for 6dof, the extra 3 "actuators" are just measuring devices that help calculate the pose. There's some papers about that on the web.

I have ideas, not much time, so for the nest release it wont have forward implemented, but like in the current release it's ready and it has already ways of feeding a pose of the rig into Mover. This allows some interesting things for the future.
Don't want to talk much about it right now , but incorporating vars into Mover was needed for this and it's something that has been in my mind from maybe the first 3.x versions.

Well I want to release till the end of the year, but my kidney... Been in pain last weeks with two interventions to remove a stone with laser, and honestlly the brain is not 100%.
For price, let's see, probably the same it was until now.

Beer, the man works for beer. Buy him some beer.

If I may be allowed to make a suggestion, set a price for the product, hopefully not as a subscription, and share the work with a collaborator because this project is really big and seems laborious to carry out alone.

If I understand the problem right, the amount of freedom the platform has in each dimension is limited depending on how far out of neutral each actuator is. But when you put a filter on each actuator, it is too difficult to figure out how this actuator filter would limit the pose.

Therefore, a logistics pose filter would need to behave differently depending on the position of the actuators. So what you need is to filter the pose according to the actuator position. So the missing link is to plug actuator commands into a pose filter. Since all actuators can act in multiple directions, you would need a filter that works in 3D space, not just on a single value. So you create a "wobbly bubble" around the pose.Is that the missing link....?