Change API of kalman tdoa estimator

[krichardsson]

I have been looking at integrating the lpsTdoaTag.c with estimator_kalman.c. My first approach was to adapt the data sent from lpsTdoaTag.c to the estimator to the API of the estimator. When looking at the code in the estimator, I think it makes more sense to do it the other way around and modify the estimator API instead.

I propose to pass the difference of distance (or in ticks) to two anchors instead of absolute time.
Benefits seems to be:

1. the estimator does not have to track clock skew (as it is already calculated in lpsTdoaTag.c)
2. we don't have to manage wrap arounds of the 40 bit clocks in the DWM chip and recreate a virtual 64 bit clock

Also, as this would change the API, does it causes problems for anyone else? @mikehamer are you using it for your system?

I have made a spike to try it out in the lab (5aca487) and it seems to work! As I lack full understanding of kalman filters it would be awesome if someone would like to sanity check the changes.

Any input on this is appreciated!

[mikehamer]

This change makes sense, given the current EKF implementation.

When I initially wrote the EKF the TDoA skew was part of the main state (instead of tracked separately), in which case its covariances with other states were non zero. To make the EKF more generic, I removed skew from the main state and tracked it separately (equivalent to assuming 0 covariance with other states).

Given the current implementation, tracking skew as part of the lpsTdoaTag makes sense, and puts it closer to where it logically belongs (since it is an implementation detail of the TDoA). If this has further benefits (eg. simplifying dealing with the DW1000-specific clock wrapping), then that's only more reason to make this change.

This change won't drastically affect things on my side.

[krichardsson]

Excellent!

Then this sounds like the way forward

Thanks!

On Fri, Nov 18, 2016 at 9:18 PM Mike Hamer [email protected] wrote:

This change makes sense, given the current EKF implementation.

When I initially wrote the EKF the TDoA skew was part of the main state
(instead of tracked separately), in which case its covariances with other
states were non zero. To make the EKF more generic, I removed skew from the
main state and tracked it separately (equivalent to assuming 0 covariance
with other states).

Given the current implementation, tracking skew as part of the lpsTdoaTag
makes sense, and puts it closer to where it logically belongs (since it is
an implementation detail of the TDoA). If this has further benefits (eg.
simplifying dealing with the DW1000-specific clock wrapping), then that's
only more reason to make this change.

This change won't drastically affect things on my side.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#163 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZZ8dJJu3SbIWGmZUTKN5xScKnBaRafks5q_ggcgaJpZM4K2h__
.

[ataffanel]

The API change has been pushed but now the input to the EKF is not time anymore but the difference of distance between two anchors. Then it seems that calling it TDoA maybe does make less sense. Can you think of a better name?