FlyPT Mover

Please, could someone help me with the LOGISTIC filter: I don't understand when I change parameter 3 "parameter 3 is how fast we go to the limit." also change the limit. Why do the actuators reduce their stroke when I decrease the speed of approach to the actual limit of the actuators, which in that case are 395?

In the first picture, I put 10 to the approach speed and in the second picture I put 0.5, which is what I would need but the extension of the actuators decrease even though I didn't actually change the position.

Thank you in advance

Look at the gray line! The red mark of the slider is the input value, the grey line reflects the post-filtering value.
To understand more easily what Logistics does, maybe open a POSE module where you can set the filters on a per axis base.
There you see a visual representation of the filter and a red dot following exactly the output:


10.0 is somewhat 'steeper' than 5.0:

where default value of 1.0 looks like a standard 'sine' wave

you can experiment with it and keep the other windows open to see exactly what and why it happens.
Good luck!

I really appreciate your help, you are right, even though this filter should let the minimum/maximum limit, in this case to stays inside the -29.9/29.9, it's actually changing according to how fast he goes to the limit.
Please can you advise me on how can I choose how fast the actuators could approach the limit without changing the range of minimum/maximum limit?

Thank you a lot

Hi,

Not at the pc right now to test, unless there's a bug, the limit should not change if you change the gain/how fast it goes to the limit.
The graphic is generated with the filter itself.

Marco, I see your point ─ and have myself no explanation for it. Now I'm looking forward to what Mastermind pmvcda will answer.
Meanwhile you may experiment with the CUBIC filter and adjust the a and c values to get the effect you want. This is an example which is not very far away from linear, but you can change the curve to anything you want:

Thank you again for your concern, CUBIC looks quite complex but in case the LOGISTIC filter will not be useful for this purpose I will try to refine the CUBIC. Yes better to wait for what pmvcda will answer before.

Thank you very much

Hi @pmvcda !
I would like connect a single Odrive-board with the latest firmware to your mover interface, but the developers from Odrive switched from counts per revolution to only revolutions. So the known strings you documented so good in your manual, will not work for this firmware.
Do you have any idea how to find the right strings/ settings for mover?
I think the matching documentation from Odrive is here https://docs.odriverobotics.com/ascii-protocol ? I am not 100% sure.
Thanks!
Wickie

Hi,

I'm not with the PC this weekend, but from what I see you need to send a decimal string.
Turns is not an integer? In the examples they use 2 turns...
I think it's a float.
So the string would be "t 0 <xxx> t 1 <xxx>"
In xxx, we need turns and I don't have it, so the work around is to use the real position.
For that you need a filter in the actuator to convert linear distance to turns.
So if 10mm is 1 turn, use a multiply by 0.1 to get the number of turns.
In <xxx> use the position <PAxis1a> to get the actuators value.

In the next build, I will try to add a dislocation by turn field and key to solve it.

I will look at it tomorrow, no PC where I am right now.

@PeterW ,

Not even sure it's worth adding that extra field.
Because we can do it in the actuator filter. It has no effect in the 3d view.
What changes is the bit calculation because it's made for that ne actuator value, but then you are not usng it.
Need to think better about it.

Thank you so much for your assistance! I tried the settings you proposed and the motor on my test bench is running somehow. Much too slow for some reasons, but it gets commands from mover! So, a good point to start.
It would be great if you could look to this topic more in depth. But no hurry!!
I highly appreciate your work like all times!
Wickie

The way I told you, -200mm in a linear actuator with an sfu1610 would be 10mm each turn so -20 turns.
Maybe it's expecting values bigger than zero, so try a filter like ADD(GAIN(VALUE;0.1);20)
This is adding 20 turns to the gain.
You have to adapt this to your actuator specs.
Your encoder is on the motor axis so multiplication is only related to the ballscrew specs.
What you add depends on your travel.

But I think that it should accept negative values.
Also, look at scale. Use 1.0, but this should have no effect here.

I made a fast update for the next build.
We are going to have a new <TAxis1a> key for turns:

A new field in the rigs let's you specify the amount of dislocation (degrees or milimeters) for each turn.
Also added a checkbox on the debug to see the final result in text instead of byte array.

I still have many loose bits on the new build. Major changes in outputs and rigs internal code.
So I need some more days to release it.

Ok, I read it better.
The logistic filter is made to allow you to send a value of 500 to something limited to 100.
What is going to happen is that the 500 value will become maybe 99.9.
A 1000 value would become 99.9999.
What this means is that we are never going to reach the 100 value. Maybe with rounding, it rounds to 100.
It's specific to the math. If you enter a value of 100, you might get 95.
It starts to slow near the limit. The gain or how fast it reaches the value has nothing to do with the limit in reality. It's just a gain for the slope.

The idea is to slow the actuator when it's reaching the limit, so if your actuator goes from -200 to 200, using logistic in 200, makes it never reach the 200 value.
Try to put there 9999 of range and a logistic filter to 200.

I'm sorry pmvcda, I'm not sure to have properly understood. maybe because my actuators are quite fast but since the real range is 395/-395 the best speed to go to the limit tested is 0,500 but this value makes become less than half the range (182.5). There is some other way to reach the limit at this speed (0.500) cutting the less as possible the range? J-1775 gave me the advice to use the CUBIC filter.

You can try a cubic variation, but try to put a big range in the actuators, like 9999.
Then add the logistic.
Try to send huge values and test if it goes near the limit.
I find half a value to low. Use 1 in the last parameter.
But, before that, send me your setup file so I can take a look (discord)

I hope to have understood where to put the 9999 value because seems to get some problem with the geometry. I attach you the config file

@Marco Annunziata ,

I see what you need.
I'm adding a new filter to Mover, to acomplish what you want.
You set the limit and how much of that limit is used for transition.
Something like this:

LOGISTIC2(VALUE;100;10)

limits values to -100/+100 and uses values 90 to and -90 to -100 to make the smooth.
I had this filter done when i made the LOGISTIC, but never added it to Mover.
Give me some minutes and I will show it in action.

@Marco Annunziata ,

I changed the parameters to:

LOGISTIC2(VALUE;range;percent)

range is the minimum/maximum value
percent is the amount of the value that is a 1:1 relation. From there it stars going to a infinitesimal approach.

Here it is with full transition 99.9%:


Half transition 50%:


No transition 0.01%:


hmmm, seems i inverted the percent.
But you get the idea. Will be in the next build.
Might change the name. Not sure...

Thank you a lot for your effort.
Just how can I set the smoothness of approaching? I mean the "parameter3 is how fast we go to the limit." in the current LOGISTIC filter

Perhaps I have understand, the "parameter3 is how fast we go to the limit." Is the deceleration curve steepness