package roadmap

[hoangsep]

Hi. We are going to use ethzasl_sensor_fusion package for our AUV. However, we have 4 sensors so we need to use multi-sensor package. So I want to ask when the msf package will be released?

regards,

[simonlynen]

Hi,

what are the sensors you want to integrate? The package will probably get released in summer.

Simon

[loechner]

Hi,

first of all, thanks for sharing this ros package! I'm trying to use it as a starting point for a robust fusion algorithm for a car like vehicle. Besides other sensors, the car has an IMU and encoders on the wheels. These sensors (IMU and encoders) publish their data synchronized at 100Hz.

The encoders are used as velocity sensors. If I use one big H matrix for all encoders, it works fine. As far as I understand EKFs, it should be allowed to serialize the update step by splitting the residual vector r, the H matrix and the R matrix in smaller chunks and calling the update step several times with the different chunks of r, H and R (e.g. A. Gelb "Applied Optimal Estimation"). If I use separate H matrices and residual vectors and then call measruements->ssf_core.applyMeasurement(...) for each sensor directly, the filter diverges and after a short time it outputs NANs.

When I looked through the code of ssf_core, I couldn't find any reason why it should not be possible to call applyMeasurements(...) several times directly one after the other with the different chunks of r, H and R. The state_idx is the same for all calls.

So my question is, why is the current code not suitable for multi-sensor fusion? Are there any updates on the release date of your multi-sensor package?

Julian

[stephanweiss]

Julian,

If you call applyMeasurement() two times with measurements with the same time stamps the first one gets overwritten by the second one:

• the first applyMeasurement() takes the time stamp of its corresponding measurement, goes back in the state history to apply the measurement at its correct place and propagates the states to the present time
• the second applyMeasurement() does exactly the same thing, but since the state in the history that matches best to the measurement time stamp did not get changed by the previous applyMeasurement() (only the following state got changed) all things will be overwritten.

The big change in the Multi Sensor Fusion (MSF) is that it can handle multiple measurements correctly even with different time delays.

A workaround in your case would be to call applyMeasurement() once and make sure that the next call uses a more recent state from the history than the first call. This is an approximation but since your IMU runs at 100Hz the time error where you apply the second measurement is maximum 5ms.

Hope this helps
Best
Stephan

---

From: Julian Löchner [notifications@github.com]
Sent: Wednesday, August 21, 2013 6:37 AM
To: ethz-asl/ethzasl_sensor_fusion
Subject: Re: [ethzasl_sensor_fusion] package roadmap (#7)

Hi,

first of all, thanks for sharing this ros package! I'm trying to use it as a starting point for a robust fusion algorithm for a car like vehicle. Besides other sensors, the car has an IMU and encoders on the wheels. These sensors (IMU and encoders) publish their data synchronized at 100Hz.

The encoders are used as velocity sensors. If I use one big H matrix for all encoders, it works fine. As far as I understand EKFs, it should be allowed to serialize the update step by splitting the residual vector r, the H matrix and the R matrix in smaller chunks and calling the update step several times with the different chunks of r, H and R (e.g. A. Gelb "Applied Optimal Estimation"). If I use separate H matrices and residual vectors and then call measruements->ssf_core.applyMeasurement(...) for each sensor directly, the filter diverges and after a short time it outputs NANs.

When I looked through the code of ssf_core, I couldn't find any reason why it should not be possible to call applyMeasurements(...) several times directly one after the other with the different chunks of r, H and R. The state_idx is the same for all calls.

So my question is, why is the current code not suitable for multi-sensor fusion? Are there any updates on the release date of your multi-sensor package?

Julian

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-23017304.

[simonlynen]

@TranMinhHoang have a look here: https://github.com/ethz-asl/ethzasl_msf