Ive been working with a BlueROV2 drone for some time now and have been experimenting with short distance movements using the IMU readings to estimate the drones position. Most of my testing has been done using the BlueROV2 simulation which has data in all fields of SCALED_IMU2 messages. When i do field tests for the drone using SCALED_IMU2 i am currently receiving 0s for all the accelerations (x, y, z). Looking into the documention for the BlueROV2 R4 there is no acceleration measurements on SCALED_IMU2 as it only has a magnetometer.
I am wondering if there is documentation about using the RAW_IMU messages and converting them to m/s^2 measurements. Speciffically do i need apply an offset to the raw readings and conversion to proper units? The IMU reads in units of g so i can apply ~9.81m/s^2 to convert them.
Hi @Amhussey -
Welcome to the forums!
The Navigator has more than just a Magnetometer, the sensor data you’re looking for is under AHRS2 - see this post.
I’d be surprised if you’re able to infer position effectively at all with this approach - please share your results!
Thanks Tony!
I am using AHRS2 to read the orientation of the drone but for translating need a source of data which would be the IMU - most likely it wont work past anything really close to the drone. SCALED_IMU2 wont work so I turned to RAW_IMU which im trying to convert to useful info. Testing in the SITL the RAW data is rotated by roll 90 degrees which is expected as the module would be rotated inside the BlueROV2.
For the RAW_IMU data that is read from the current sensor what needs to be done to get measurements in m/s^2? Part of my testing to see how fast the error in position grows using only IMU measurements and finding ways to minimize this.
I haven’t looked at this in a while, and we don’t currently have decent documentation describing these values. Hopefully this comment (from a while ago) is helpful:
Thanks that did help. Ran some tests in SITL and found that the RAW_IMU readings are also in mG. measured the z acc to be ~ -10000 as expected. I’ll have to run the program on my Rov2 to be sure what units are being measured on the drone itself and the conversions are based on the config of the IMU. I cant find any documentation on if the default has been changed would it still be operation in the +/-2g scale range?
This is the IMU sensor in the Flight Navigator: ICM-20602
I’m not sure where you got that range from. I would presume if the sensor experiences accelerations outside that range then it would reflect them if it is able to.
Spent a long time working on the program. For anyone who’s curious:
The IMU is reading accelerations in mG.
Wrote a simple program to read acceleration and write it to a csv file over 10 minutes. Applied a rotation to the navigation frame to account for the projection of gravity onto the horizontal plane.
Tested the program applying constant roll and pitch to the drone by propping it up with a box this resulted in the acceleration having a slight offset from the roll causing any IMU readings to have greater error accumulation.
Accounted for the offset in the acceleration in y and now have data that could be used for short-term IMU navigation.
Were starting our live testing of the control system and will upload once we get some data on how long navigation is viable for. This could be used for a dual use GPS, IMU navigation for passing surface obstacles
Slightly different question here, but in the same vein. I have just been using the .tlog files that I have decoded into csvs using mavlogdump.py, but in those files, all my accel and gyro values for SCALED_IMU2 are all 0 for the whole log. This is a consistent problem, across many different BlueROV2 trials. In the mavlink messages html guide, they say scaled IMU2 is for a second 9DOF device. In other blue robotics posts, like this, I’ve seen people use them. I’m just a little confused and would appreciate some clarity on why they are maybe 0 for me, and why don’t we use SCALED_IMU1, for example (which, I know, is not an offered variable in the tlog files atleast)
Just a bit more info: I am getting data in RAW_IMU and ATTITUDE columns. I’ve read on other posts recommendations to not use the RAW_IMU data for any sort of dead reckoning (or the scaled IMU for that matter, but it seems scaled is better for it if you really want to do dead reckoning)?
Could this be fixed by using the dataflash logs instead of the tlogs?
Hi @coanderson -
Rather than IMU messages, if you’d like information on vehicle pose simply checkout the ATTITUDE message. This is available in the .BIN log that can be analyzed with this tool.
The IMU messages you are looking through are not expected to have the data you’re after!
In general, none of the IMU data is going to be of sufficient quality to accomplish dead reckoning via double integration of the values to estimate position…
I’ve moved your post here because it’s on a more related topic.
Assuming you’re using our Navigator board, there is only one IMU, so only data for one IMU gets sent in the telemetry. Systems using a Pixhawk or other flight controller board may have two.
As per further up in this thread, ArduPilot actually sends RAW_IMU and SCALED_IMU2 with the same scaling - it’s just a difference of which piece of hardware is being read from.
Dead reckoning isn’t recommended because of both the quality and frequency of the IMU data, and because the double integration of accelerometer data into position estimates also involves doubly-integrating the error, which can lead to significant, rapid error buildup.
Dataflash logs will provide higher frequency data than the tlogs (because the autopilot records more values internally than it typically sends through telemetry), but that doesn’t help with the data quality issue (e.g. due to sensor noise), as is discussed elsewhere on the forum - this comment may be worth a read.
Hi Eliot and Tony! Thanks for this info and for moving it to this post. The attitude pose values are very helpful, but we are also looking for x,y,z accelerations – so will use RAW_IMU as mentioned above.
We know the IMU is quite error prone, but are hoping when we incorporate some more of our sensor data we can periodically correct it (crossing our fingers, but not counting on it). In our SLAM algorithm we are trying to make, we hope to rely on other sensors, not the IMU. This is just how we are starting our process.
This is helpful though to know where to look! I will start using the bin files instead of the tlogs
Note that the internal DataFlash (.bin) logs use a different message format than MAVLink. You likely want either the ACC messages (for just accelerometer data), or the IMU messages (for more fleshed out IMU details).
Hey Courtney, we’ve gone through a couple methods to try and correct control using IMU data. Our current step is to measure a pulse characteristic control model of the drone to assist the IMU data in estimating the position on time. Its a tedious process of sending control and measuring the physical distance the drone moves but should give a longer period where control can be used.
All my testing of raw IMU measurements to position had the same issues as everyone expects. Continous small error in the IMU readings accumulate pretty quickly. We tried to add a drag component to velocity calculation to limit the amount of small error build up but resulted in undershooting of the target.
Hi @Amhussey -
Sending control and measuring a displacement sure does sound tedious! I’d also be concerned that in different environments (particularly those with water currents) and at different battery voltages, those distances would vary wildly… hopefully that’s not an issue for your approach to the problem!
