Assistance with Profiler / LFS data rates

Hi,

I'm debugging PID control software which is reading axis outputs from Force Profiler shared memory for use with my external servo control hardware. This is runnng well, however I have a question regarding the apparent refresh rate of the axis data in the shared memory area.

I'm using an unactivated version of LFS with the LFS Force Sender Plugin from the drop down list on the Force Sender window for my software debugging.

I'm reading the axis data at roughly 65-70Hz, the Profiler Math engine is running at 73Hz (from Profiler window), LFS framerate is about 90 Hz. I have set the Force Sender comms delay at 12ms, and the OutSim Delay parameter in the cfg file is set to 1.

From analysing data traces from my software it looks like the Profiler shared memory axis data is being updated approximately every 45 ms (22Hz), which is slower than I had anticipated. Intermediate shared memory reads at the higher frequency return duplicate values until (apparently) the data is refreshed in shared memory at the 22Hz rate. I'm not too familiar with the X-Sim software so it is quite possible I have missed at setting somewhere. Is there another setting which might be limiting the rate at which the LFS data is being sent to Profiler, or the rate at which the Profiler shared memory is updated?

Running on a Vista 32bit dual core machine, I don't notice any substantial frame rate drops when the software is all active. I have tried increasing the Profiler Math engine rate and the LFS frame rate with no apparent improvement.

Any suggestions on things to check would be appreciated....

Ian

There are three timing related settings that effect this.

Force Sender -->Change Polling Speed
Force Profiler-->Program Settings-->Artificial Break of Math Engine
Force Profiler-->Program Settings-->Artificial Break of Synaptrix

Thanks Bernhard,

I have these set at 12ms, 13ms and 8ms respectively, so had anticpated that the slowest (13ms) would set the update rate, but there seems to be something else...

I may look at the LFS UDP data directly to see the data refresh rate.

Ian

...looks like the UDP data packets contain new data sent at the LFS framerate, so it's not an LFS issue.

Hmm...

Ian

Thanks SirNoName for the information.

Please pardon my lack of familairity with your software, can I check that I have understood properly...

Is the gauge section sourcecode you quote Force Prolifer code, Force Sender code or LFS plugin code? ie does the ~50 updates per second always apply to shared memory axis data because of the Profiler or Sender code or does it only apply to this LFS plugin?

I will try the data logger to confirm update rates, and I understand Windows is not a real-time OS.

Ian

Every motor with pot or other position feedback is by definition a servo, not only those tiny little RC ones.
As far as I interpreted Ian's initial post, he wants to control simulators with PID, which he tries to debug currently, not gauges.
The PID algorithm to control motors on the other hand, comparing to gauges, needs a high data input speed.

Regards

Hi egoexpress,

Yes, you are correct, my hardware drives motion platform motors, not gauges - perhaps my reference to servo has given confusion, I didn't mean RC style servos.

See - http://buggies.builtforfun.co.uk/Sim/SPU.php

...for clarification of the system. I have this running with X-Sim axis data output either from shared memory, or USO, although shared memory is more convenient.

The PID control is applied to the motor speed control loop, and it is the D term that is most sensitive to position demand data refresh speeds that are slower than the servo loop refresh speed.

My question related to the data refresh rate for the axis data (not gauge data, although for all I know this might be the same) in the Force Profiler shared memory area.

Ian

IMO the Software PID solution is a waste of time and effort. Even if you have 1kHz update rate available for calculations, there are way too many delays in the hardware loop that defeats the whole purpose of fast update rates.

Potentiometer -> 64SPU-1 -> USB -> Software -> Calculations from game data -> USB -> 64SPU-1 -> I2C(worst option) -> Motor Driver

There is just too much lag time in the control loop to be accurate. The other downside is not being able to tune the I and D terms properly due to the ever changing time base of the calculations (Windows being non-RTOS).

With a simple hardware PID controller it is fairly easy to get 100-200Hz updates from the USO/Synaptrix and run a 1kHz PID output loop, while keeping a comfortable 1ms time base that doesn't change upon CPU load.

Hi Frakk,

I see you are not a fan of software control.

The update rate of the system is as I explained at roughly 70Hz, and this is satisfactory for a reasonable low-cost flight sim experience. I find that P and I terms are not difficult, I especially is an integral of error and does not need fast refresh rates to be useful, nor does it need consistent time steps (within reason) to be tuned usefully. The D term is susceptible to noisy demand or feedback or slower data rates, however even it can provide a useful contribution to controlling overshoot due to higher P terms with these kinds of loop rates. The bigger problem I find regarding the utility of the D term is noise on the feedback not refresh rate.

For low cost approaches I would disagree with your assertion that Software PID solution is a waste of time and effort. I have found it to be workable and functional. However perhaps my flight sim application is less demanding than racing sims given the softer dynamics.

Hardware solutions are offcourse available, - you pay your money and take your choice.

My purpose in posting was to ask a good faith question on the shared memory data refresh rates.

Ian

PS why is I2C to MD03 speed controllers the worst choice? It is reliable and it works.

Please don't get me wrong, I'm not trying to disencourage you by any means. It is always good to have different options and I won't post about hardware- vs software PID anymore.

If you are looking for a low cost, low performance controller for slow moving flight simulators the software approach might be sufficient. The problem is not the refresh rates, as 70Hz should be sufficient for a good feel, but the delay and speed of the loop's response.

I looked into the prices of the cards, and to be totally honest the 64SPU-1 and related hardware are fairly expensive for what they do. It would take pretty much no effort to re-program the controller card to take care of the PID calculations, and you wouldn't even need any other software package.

I2C is not meant for board-to-board communications. It is meant for on-board communications between IC's in close proximities.
How reliable is it if they have to give these directions?

Max wire length between 64SPU-1
and MD03's – 300mm.
Avoid loops in the logic GND wiring.
Keep 64SPU-1 AWAY from high
current end of MD03's.


Forgive me for hijacking, I will stop now. Hope you can get proper refresh rates and share your findings with us!

Hi SirNoName,

I find the D term of the control useful when adding some higher frequency response to the control system for the on-ground stages of a flight (touch-down bumps, runway bump effects etc). This higher frequency response doesn't need to be perfect for it to be useful - as is the case in many technical solutions.

The MD03 motor controllers are 20 Amp units, and there are other controllers at 50Amp - so there is some capacity for force levels to handle the effects.

@Frakk

You are saying that I2C comms with MD03 controllers is not reliable. You suggest that the advice I give is evidence of this unreliablility.

I think the advice I give is good practice on layout and I don't think this constitutes an admission of unreliability. There is no practical difficulty in keeping the I2C lines short, the advice on keeping some physical separation between logic level elements and lines and power elements and lines seems sensible to me - why mix these up when you don't have to? This advice together with the ground loop comments are also there because it is explicit advice given by the MD03 manufacturers which I think is sensible and which is sensible to pass on. Ground loops in wiring can cause problems - why not remove the possibility by wiring properly?

I have used MD03 controllers with I2C for several years and have found the comms to be solid and fast when used with the manufacturer's instructions. I understand however that your own experience with MD03's and I2C might be different.

Ian

Ian, I did not say that the I2C won't work. It obviously works as you have been using it.

All I say is that I2C (Inter-Integrated Circuit) was never really meant for communications between boards, especially not in a heavy noise environment like in our case. You ask any electrical/electronic engineer, they will say the same and would never use it to control 20-50A inductive loads. It is just a poor design decision and you won't likely see it on any commercial name products. I understand the MD03 is a hobby level controller (although 45GBP is not hobby level for an H-Bridge) and take it for what it is, without much expectations.

Of course there are no fine lines of what can be used and how, there is always an overhead and flexibility in communications, if you take extra precautions you can get more out of a lot of things than what they were meant for. If the speed is fast enough for ex. you can get away with missing bits and errors, CRC can be used to reassemble lost data, and so on...

I just really don't like the idea of controlling multiple 500W DC motors on a lousy 2wire I2C bus, especially when these motors are moving ME. That is all...

I did not say that the I2C won't work

...you said it was the worst choice and you clearly implied unreliability, apparently on the basis of no direct experience with the product.

Why does the 2-wire I2C bus have to be lousy, and if the device works reliably as advertised why is it a bad design decision just because it doesn't conform to your expectations of historical use?

Perhaps it is just your choice of language that throws me?

I said it before and I will say again:

By no means I want to disencourage you and neither I say that anything is wrong with what you do. I am grateful that we have a member like you trying new and different things, someone to contribute to our discussions. I also said I don't wish to hijack the thread and will stop commenting on these things.

doesn't conform to your expectations of historical use? - come on now..
To be more precise here, the hardware layer of I2C doesn't meet the standards of what I would consider using in such an environment and devices.
My basis is not historical use, but rather the electrical characteristics. If you care to read more: http://www.nxp.com/documents/user_manual/UM10204.pdf

For one last time please let me sum up what I am saying here:
It obviously works as you have been using it.
All I say is that I2C (Inter-Integrated Circuit) was never really meant for communications between boards, especially not in a heavy noise environment like in our case.
...if you take extra precautions you can get more out of a lot of things than what they were meant for.

I might not have experience with the exact hardware you are using, however I am quiet familiar with electronics and there is a reason to what I say.

I am very sorry if you found anything insulting or disrespectful, by no means I had intentions like that. English is also not my mother language, so there might have been a bit of misunderstanding in the tone or language we use. Me saying that I2C is a bad choice on behalf of the designer does not mean it was a bad choice made by you. I actually very like the MD03 and it's smart little features, and from a lot of perspectives it is a very good choice of hardware for your purpose.

Having said all that, you can PM me if you would like more information on the hardware side of things, or open a new thread if you think the topic is worth to make public.

Now let's figure out how you can make the full PID work properly with your software and X-Sim. :