Hi, Is it possible that IMU brick can work faster and be more precise without or with hardware upgrade?

 

Exsample IMU brick use like a gyro in RcHeli where real gyro have to:

- read data from sensors

- calculate how much is have to change rudder servo using PWM

- Send signal to servo

all things in rate 760 µs

 

same in auto stabilization, but for all 3axis.

Aver USB you can't reach 760µs for this, unfortunately. The polling frequency is 1khz, which means 1 message per ms.

But if "On device programming" will be possible then ?

 

Q2: is it possible to change onboard algorithm to be less sluggish, and more acurate ? 

even if i use callbacks, imu.SetQuaternionPeriod(2); and try diffident value for SetConvergenceSpeed its still can by only only as toy not a tool, but i truly hope that will change in future.

 

Have you played around with the convergence speed?

//EDIT

 

Yes. I will try to Update all my brick-s and brickets to new protocol, and try again. Its look like to me that gyroscope sensor used in IMU feeds to much error in sensor data to Kalman Filter algorithm.

Look on this IMU (its way more faster, and accurate on wireless then Tinkerforge IMU over USB) http://www.x-io.co.uk/x-imu-demos/ and watch first movie, its working exceptionally well

 

Using this IMU to log walking path

 

This open source project implements Madgwick’s AHRS and IMU algorithms in C# and demonstrates their real-time performance alongside the x-IMU‘s own propriety algorithm. The source code also includes Madgwick’s implementation of Robert Mayhony’s so called ‘DCM filter‘ in quaternion form.

 

 

 

Maybe it will be an inspiration to improve Tinkerforge products.

Sure impressive, but that IMU also costs 3 times more than the Tinkerforge IMU. I don't think you can expect the same performance from both...

 

But if you know something about how to improve IMU algorithms, I'm sure Tinkerforge will appreciate your help on that subject.

But if you know something about how to improve IMU algorithms, I'm sure Tinkerforge will appreciate your help on that subject.

If I knew how, it would long ago did.

 

 

Sure impressive, but that IMU also costs 3 times more than the Tinkerforge IMU. I don't think you can expect the same performance from both...

 

If its good then even at 3x price of TF IMU there is a market for it, u can take my word for it. If it will be on stock, the price is not a problem, for me 1.6m diameter spinning Rc heli blades at 2200 rpm is question of safety me and others in rage, and safety of expensive payload. TF have bright and shiny future, and i hope that they will be the best on the market, but they still have a lot of work to do.

x-IMU does use Madgwick’s AHRS and IMU algorithms, which we use too! So they either

 

1. made the video with a very well calibrated and tweaked IMU,

2. have a better parameterization of the algorithm or

3, just use much more expensive sensors.

 

I would bet that it is a combination of 1. and 3. I probably could make a very similar video if i tweaked one IMU long enough.

 

When say that "its way more faster", what do you mean? Do you mean the 3D rendering lags behind?

 

And about the accuracy: Have you tried to recalibrate the magnetometers in your environment?

"its way more faster" i meant that in current version TF Imu transmit data to slow over Wi-Fi extension to be able to use it. I have try use it in head tracking application for use in computer game "Euro Truck Simulator 2". Its work ok over USB. I will try re calibrate Imu when i will have free time, but first i have to read how to accomplish that.

Oh, but over Wi-Fi you will always have the added latency. I don't think there is anything you can do about that. If you connect the IMU to a PC over USB and then connect with to the IMU with another PC over Wi-Fi, you will get the same latency.

The latency over Wi-Fi is bigger then over Bluetooth?

I don't know anything about Bluethooth, but i would expect that it has a lower latency then Wi-Fi. It is used in mice and such, which likely wouldn't work very well over Wi-Fi.

x-IMU code is open source. So if u have some time for try to implement in TF IMU and test it how its work i will be more then happy

 

https://code.google.com/p/imumargalgorithm30042010sohm/downloads/list

Again, we use the same algorithm. The link you posted is even in our documentation: http://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_Brick.html#how-it-works  .

Again, we use the same algorithm. The link you posted is even in our documentation: http://www.tinkerforge.com/en/doc/Hardware/Bricks/IMU_Brick.html#how-it-works  .

 

sorry did't get that first time.