ethz-asl / mav_dji_ros_interface

Interface of DJI autopilot based on its OSDK (3.2)
Apache License 2.0
161 stars 57 forks source link

Logs for calibration and testing of ZR300 #15

Closed mauricefallon closed 7 years ago

mauricefallon commented 7 years ago

From Maurice: To get started with this I would like to use the RealSense Z300. Do you have any logs and configuration files with that sensor?

From Inkyu: In order to use Realsense ZR300 (Z300?) with MSF and Rovio presented in the work, you need to calibration it carefully. I didn’t get what the logs imply but all configuration files are located at https://github.com/ethz-asl/mav_dji_ros_interface/tree/master/dji_interface/cfg/raven

mauricefallon commented 7 years ago

Just to re-phrase: Could you please provide a ROS bag of a log/dataset of the ZR300 for calibration and a datalog of it in an experiment

inkyusa commented 7 years ago

Dear, Mauricefallon Please have a look our wiki page, https://github.com/ethz-asl/mav_dji_ros_interface/wiki/Sensor-Calibration, for ZR300 calibration. We also provide ROSbag dataset that used for this project. If this answer resolves your questions, please close this issue. Best.

mauricefallon commented 7 years ago

Hi @inkyusa, I've spent a big amount of time trying to get Rovio to work with the calibration ROSbag - without any success. (It works just fine with the MH01 log)

When I run Rovio when playing this bagfile, the processing is really slow - at about 1fps. (But the data is at 30fps). The feature patches drawn in the opencv UI are mostly unstable - with red boxes and huge ellipses (in yellow).

I'm using the imu '/falcon2/imu/compensated'. Have you been able to get this log to work with Rovio yourself?

(I'm using rovio_cam0.yaml and rovio_filter.info from the raven folder mentioned above)

ZacharyTaylor commented 7 years ago

Hi, just thought I would add my input. If the processing drops down to 1 fps this usually means ROVIO has diverged and can no longer find any features to track. This can happen for a large number of reasons, one possibility is if the rovio_filter.info file is missing or contains an invalid entry rovio will try to generate a new one with default values and run off this instead. However, these defaults generally won't fit the camera and IMU. Easiest way to check if this is the issue is to turn frame visualization off in the config. If you still get it visualizing, rovio is not actually finding/using your config file.

Another possible problem is that the bias terms for the IMU were incorrectly estimated. This can be an issue for the realsense cameras as their IMU is right at the lower end of what rovio can work with. I recently got ROVIO up and running on an Intel Euclid which seemed to have an even worse IMU then the ZR300s I had previously used. My rovio .config file had to have much much higher bias values to get the estimates to remain stable. You can see the parameters I used here https://gist.github.com/ZacharyTaylor/3fb8dc125e5a84b15333b595cb37690c

mauricefallon commented 7 years ago

@ZacharyTaylor , that's awesome, thanks a lot! It was generating a new info file and not reading the intended one. All is fine now.

@inkyusa I needed to add a velocity block to the rovio config file

VelocityUpdate { UpdateNoise { vel_0 0.0001 vel_1 0.0001 vel_2 0.0001 } MahalanobisTh0 7.689997599999999 qAM_x 0 qAM_y 0 qAM_z 0 qAM_w 1 }

this video might be useful to other newbies

fmina commented 7 years ago

@mauricefallon Indeed, this velocity update block is new and we have to add it to rovio filter info. See #16

Thanks!

mauricefallon commented 7 years ago

Hi @inkyusa , sorry to bother you again on this issue. The rosbag you provided for your zr300 contains IMU data at 200Hz.

My own zr300 outputs at 430Hz. I can't see any flag for setting it to publish at 200 nor a setting in the driver or rovio. Is it necessary to correct for this or is rovio smart enough?

ZacharyTaylor commented 7 years ago

The zr300 asynchronously outputs acceleration data at 250 hz and gyro data at 200 hz. The official driver just dumps this all into one message stream and from memory also doesn't bother timestamping it correctly. You need to use our fork where we stick the data into one message and sync it with the system clock.