search

ethz-asl / ethzasl_sensor_fusion

time delay single and multi sensor fusion framework based on an EKF
327 stars 161 forks source link

Getting started with ethzasl_sensor_fusion #5

Closed aswinthomas closed 11 years ago

aswinthomas commented 11 years ago

Forwarded communication from Gmail. Could be useful for everyone.

Aswin Thomas aswinthomas@gmail.com 10:39 AM (22 hours ago)

to stephan.weiss Hi Stephan, Your sensor fusion ROS package looks awesome and would like to try it out. I have tried ethzasl_ptam and have got it working. I want to try the effect of having an IMU added to the system. I have no robot an just want to try a handheld approach in an indoor environment.

1) Should I be using ssf_updates? 2) Should pose_measurement be mapped to vslam/pose? (ptam topic) 3) For imu_state_input i am using the xsens_driver at 100Hz. Is this ok? I understand 1kHz is ideal, but just want to try the system. Any other IMU you recommend? 4) How do I publish to hl_state_input? Not sure how to run the sensor_fusion_comm.

Is it necessary to have an asctec quadcopter?

Regards

Aswin

Weiss Stephan 1:04 AM (8 hours ago)

Hi Thomas,

Thank you for using my framework and I am glad that ethzasl_ptam is already working for you.

If you are aiming at a self-calibrating state-estimation framework using IMU and ethzasl_ptam then you should definitely use ethzasl_sensor_fusion (i.e. a sensor module in ssf_updates). Note that this is a loosely coupled system - if you want to improve PTAM performance by including IMU information (i.e. tightly coupled approach) ethzasl_sensor_fusion is not necessarily the way to go.

assuming the you have a self-calibrating state-estimation framework in mind: 1) ethzasl_sensor_fusion consists of a core part which always uses the IMU as a EKF propagation sensor and an "update" part. In the "update" part you define your own update sensor module (such as a 6DoF pose sensor when using ethzasl_ptam). If you use ethzasl_ptam then you can directly use the provided module "pose_sensor"

2) yes, that is the input for the update-callback for the EKF

3) The mapping is correct. Be aware that 100Hz is slow but ok as long as the vision update is slower. We usually use the IMU on the asctec helicopters, but any IMU is fine - the filter should be able to deal with significant noise levels of poor IMUs.

4) You do not need to publish hl_state_input. This is an alternative topic to imu_state_input published by asctec_mav_framework when using asctec helicopters and doing the EKF prediction step on the helicopters micro controller. If you are not using asctec helicopters then the general IMU topic imu_state_input should be used.

You are perfectly fine not using asctec helicopters. You just feed the IMU prediction topic to imu_state_input and the camera update topic (vslam/pose) to pose_measurement. If you go to flying platforms the asctec ones just provide a good interface (1kHz IMU) and things are tested and verified with our framework.

If you don't mind, could you post this to GitHub such that we have a ticked other users can also consult? Also, please check the tutorials for ethzasl_sensor_fusion on www.ros.org/wiki/ethzasl_sensor_fusion/Tutorials and if you have time, please let me know we can improve them to answer your questions there.

Lot of success with our framework and let me know if I can help you in anything else Stephan

aswinthomas commented 11 years ago

Hi Stephan, Thank you for the detailed explanation. Will try it out.

I did not see the tutorials link previously. Its a good read.

Regards Aswin