Comments (6)
Thanks for the super clear problem description. I've tried reproducing the problem. I'm currently still using ROS1 Noetic, so I've converted your ROS2 rosbag to ROS1 format using ternaris/rosbags and ran the current ROS1 version of imu_filter_madgwick. Here are two videos of the results:
video 1 (gain = 0.1)
imu_gain_0.1.mp4
video 2 (gain = 0.01)
imu_gain_0.01.mp4
Video 1 shows:
- your Zed2i data (without magnetometer)
- your imu_filter_madgwick data
- my imu_filter_madgwick data (no magnetometer, gain = 0.1)
- my imu_filter_madgwick data (with magnetometer, gain = 0.1)
Video 2 shows:
- my imu_filter_madgwick data (no magnetometer, gain = 0.01)
- my imu_filter_madgwick data (with magnetometer, gain = 0.01)
Some things I noticed:
- Your data (2) is the noisiest of all. What parameters did you use? By reducing the gain from the default 0.1 to 0.01, I could reduce the noise a lot, at the cost of slower convergence (compare (3) vs (5) and (4) vs (6)).
- The data frequency is extremely low (< 10 Hz). Usually, I work with IMUs that produce data around 250 Hz. That's just a side remark though, as long as the data is good this shouldn't be a problem.
- I could reproduce the problem you were describing! In (4), the filter clearly converges to a different yaw after tilting, and then again to the previous one after tilting back. In (6), this effect is still there, but much less noticeable because of the lower gain. That doesn't mean the problem is fixed though: It will still converge to the wrong yaw, only longer.
I believe I found the cause of your problem! Your magnetometer axes doesn't match the IMU axes (as I suspected from the beginning). If you look at the videos, you can see that the device is rotated around the y axis. However, the magnetometer data is rotated around the x axes. You can also see that in the following plot:
The green line (magnetic_field/x) and the bright blue line (linear_acceleration/y) stay flat, indicating that these are the axes that are rotated around. This means that these axes are either parallel or antiparallel.
I suggest that you perform a couple more experiments like this with other axes to identify which axes correspond to which other axes (and what the signs are), like this:
x_acc = -y_mag
y_acc = x_mag
z_acc = z_mag
(This is just an example!)
Then you can easily write a converter node that adapts the magnetometer data.
from imu_tools.
Great, you solved my issue !
In fact, I misunderstood the IMU standard. That's why my axes was wrong... Configuring it like you suggested with PlotJuggler solved it.
For those reading this : to determine if axes are parallel or antiparallel, you should check the derivative sign of their slope. For example, here we see that y and x are antiparallel. (correct me if I'm wrong @mintar )
Thanks for your help !
from imu_tools.
The imu_filter_madgwick assumes that all input data is in the same frame; it doesn't do any TF transformations of the input data. If your magnetometer and your gyro/accelerometer are in different frames, you can probably get away with it as long as they are fixed relative to each other and have the same orientation. In other words, if the IMU is flat on the table with z pointing upwards, and the magnetometer points in the y direction, then if you rotate the whole thing counter-clockwise by 90°, then the magnetometer should point in the x direction. And so on for the other 2 axes.
You should probably plot the magnetometer readings, the rotational velocities and the linear accelerations using PlotJuggler while rotating by 90° around all 3 axes (and writing down what you did), and also visualize the IMU/magnetometer topics/TF in RViz.
from imu_tools.
Thanks for your answer ! Here are the the my frames :
Using PlotJuggler, I verified that the IMU follows this convention for angular velocity and linear acceleration (and it does).
I've also verified that my magnetometer is ENU based.
But still have this tilt issue.
Moreover, I don't understand your sentence "have the same orientation.". In my understanding, magnetometer gives absolute (ENU) values while IMU gives relative values. So I don't understand how I can set the mag_link frame and don't understand how it can affect the output. I've checked the madgwick code and observed that this frame id isn't use at all. Can you clarify it please ?
from imu_tools.
Moreover, I don't understand your sentence "have the same orientation.".
By "have the same orientation" I meant that there is no rotation between the IMU and magnetometer frames. But from your screenshot it looks all good.
In my understanding, magnetometer gives absolute (ENU) values while IMU gives relative values.
Yeah, you are right. One exception though: The accelerometer of the IMU measures gravity, so that's an absolute value as well.
Anyway, could you record a rosbag (all input topics of imu_filter_madgwick + TF) and a video that shows the problem that you have?
from imu_tools.
Thanks again for your help !
The experiment
The imu is in the camera while the magnetometer is on top of this setup. You can observe that the URDF (and consequently the TF) doesn't represent it exactly. That's because I tried to simplify the setup as much as possible to avoid noises. I don't think it can influence the result.
3 steps :
- Initial position : eyes towards south (more or less). See image 1
- Tilt. See image 2
- Back to initial position (image 1)
![image 1](https://private-user-images.githubusercontent.com/7413624/323546874-53e5cb6f-acb4-467d-9347-d8909fe16a81.jpg?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTc4NDQ2MDQsIm5iZiI6MTcxNzg0NDMwNCwicGF0aCI6Ii83NDEzNjI0LzMyMzU0Njg3NC01M2U1Y2I2Zi1hY2I0LTQ2N2QtOTM0Ny1kODkwOWZlMTZhODEuanBnP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDYwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA2MDhUMTA1ODI0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YzZkNzE3MzU2MzAwYjllNDc3NjAzNzU0ODE2ZWU2MGI4MTUzMjcwY2FmZWJjZTNmYTZiNTdhOTY3ZjYxMWI3MiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.HYzSQfd_AdcQ-_62G0Agp4jBaSuudNgAFT2-uka2JZY)
![image 2](https://private-user-images.githubusercontent.com/7413624/323543263-9a329f2f-bf6f-477e-9e33-1b82e7181b62.jpg?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTc4NDQ2MDQsIm5iZiI6MTcxNzg0NDMwNCwicGF0aCI6Ii83NDEzNjI0LzMyMzU0MzI2My05YTMyOWYyZi1iZjZmLTQ3N2UtOWUzMy0xYjgyZTcxODFiNjIuanBnP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDYwOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA2MDhUMTA1ODI0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MzE2NzhlY2Y2YzhkNzEwM2U1NTg3OTU2ZTY4Y2E1ZDU0MWI3Nzg1ZjAyYTU3MTVhYzc1MzkyNzZjMzhhZDEyYyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.3H_gOLW6gJb3JeXm-XF8oKds41jNrd2C9m0c8dGAITI)
Observation
The upper graph is the output of the madgwick filter while the other one is the orientation outputted from the ZED2i camera and SDK (I think it is computed based on an internal madgwick filter based on the IMU but I'm not sure. It is a relative value.).
You can see that when we go from step 1 to step 2 (red line on the graph) that the madgwick output yaw drifts a lot (from -2 to -1.3) while the yaw computed from the ZED2i camera stays constant (only a small noise because I'm not a robot). I expect a constant output from the madgwick aswell, that's the issue I try to solve.
Rosbag
Here is the rosbag to reproduce the experiment. I've included the inputs of the madgwick, TF and the output of the madgwick so that you can really see the issue.
rosbag2_2024_04_18-11_12_22.zip
Hope you will be able to guide me. Thanks.
from imu_tools.
Related Issues (20)
- Yaw Angle in ENU HOT 1
- Unable to visualise `/camera/imu` in Rviz HOT 2
- CMakeLists / findpackage improvements HOT 1
- How to get x, y, z values from IMU? HOT 3
- Problem with magnetic use complementary filter HOT 2
- Transform between IMU data and Mag data HOT 2
- Unstable and slowly changing output data in madgwick filter HOT 3
- Unable to set ~publish_debug_topics to True for imu_complementary_filter HOT 1
- Confusion in filtered quaternion results HOT 1
- Make "do_bias_estimation" reconfigurable during runtime
- output of imu_filter_madgwick is skewed over time HOT 2
- how can solve this problem? HOT 1
- Yaw offset compared to Ignition Gazebo IMU System HOT 1
- Incorrect variance calculation HOT 2
- rviz2 visualization unstable
- Is it normal to get these errors using Madgwick filter?
- Relsense Depth camera imu data filtering using mdgwick filter but its not giving stable and correct values HOT 1
- "odom" passed to lookupTransform argument target_frame does not exist. HOT 3
- 亲测可用,只是要从cpp中修改订阅的imu话题
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imu_tools.