If there is no new information available to the proxies, Read will block until new data is available (or until it times out), as is specified in its function documentation . ReadIfWaiting will return immediately if there is no new information available, otherwise it will proceed to call Read(). Read() takes a little bit of time to complete, which may vary slightly depending on how many interfaces it needs to update.
The variation you’re seeing in Read() just depends on when you call it vs. when new information is available. The variation you’re seeing in ReadIfWaiting is probably due to it returning instantly in the same instances during which the call to Read() would block. There is a function called Peek() which will let you know if data is available for the Read() function.
How quickly do your sensors publish updated information? Running a Kalman filter faster than your sensors are able to publish data is pointless, you want to have at least some new information at the end of each time step. Usually people run them synchronously with a sensor reading or slower. These long Read() delays might indicate that you are trying to run your filter at a frequency much faster than you’re getting new sensor readings.
After my mail yesterday I have tried to dig through the code and also looked into the fixed timestep, dt, since a Kalman filter needs a fixed timestep for its prediction step.
But I have noticed that the command "robot.Read()" has a very long and very uncertain delay which is found to be between 70 to 115 ms.
- How can it be that the "Read()" command takes such a huge amount of time.
- Is it possible to use a different approach that is more stable? "ReadIfWaiting" is also producing some very unstable results in its process time.