ECEF coordinates

[Mike]

Hello, 

Has there been any experience working with ECEF(global) earth coordinates? The scales are much different than using local NED. We are potentially interested in using this coordinate system but I am wondering if this will create issues related to poor conditioning during optimization. Would be interested in any prior experience on this.

- Thanks 

[Dellaert, Frank]

Hi Mike

Yes, it can create ill-conditioned systems If you are solving linear systems directly with those coordinates - e.g., chordal initialization, especially if your covariances are small compared to the coordinates, which is typically the case for ECEF. I did experience that when looking into linear initialization methods and I was doing examples with satellites. 

However, when you linearize in a non-linear optimization problem, typically these problems disappear. That being said, my experience with ECEF is limited. 

Frank

From: gtsam...@googlegroups.com <gtsam...@googlegroups.com> on behalf of Mike <lowel...@gmail.com>
Date: Tuesday, January 20, 2026 at 5:35 PM
To: gtsam users <gtsam...@googlegroups.com>
Subject: [GTSAM] ECEF coordinates

You don't often get email from lowel...@gmail.com. Learn why this is important

Hello, 

Has there been any experience working with ECEF(global) earth coordinates? The scales are much different than using local NED. We are potentially interested in using this coordinate system but I am wondering if this will create issues related to poor conditioning during optimization. Would be interested in any prior experience on this.

- Thanks 

--
You received this message because you are subscribed to the Google Groups "gtsam users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtsam-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gtsam-users/35ec23e5-f1f5-442f-9b91-4908a911fe3bn%40googlegroups.com.

[Mike]

That makes sense, one other question - I realize that depending upon the range, gravity vector will also need to be part of optimization process and depends on current location.

Can the gravity vector also be optimized for if we implement a function that generated a gravity vector per ECEF coordinates? I understand you supply the gravity vector but as far as I know it's static, grav model could either be analytically or numerically differentiated.

[Dellaert, Frank]

I’m assuming you’re talking about the IMU factor. if that’s the case every PIM can have a different gravity vector; so you just have to create a PIM with a different parameter struct. That being said, I personally never tried that so you might run into issues that we did not foresee.

Best!

Frank

---

From: gtsam...@googlegroups.com <gtsam...@googlegroups.com> on behalf of Mike <lowel...@gmail.com>

Sent: Tuesday, January 20, 2026 8:18:10 PM
To: gtsam users <gtsam...@googlegroups.com>
Subject: Re: [GTSAM] ECEF coordinates

 

To view this discussion visit https://groups.google.com/d/msgid/gtsam-users/556c5666-c686-47df-9408-c9e276a14270n%40googlegroups.com.

[Radu Cioaca]

Hi,

I used ECEF coordinates in factor graphs that were not using the IMU Factors. I was using other sensors or model propagation assumptions and it worked pretty well I had no numerical issues. 

When I started adding IMU factors, I switched to defining the internal state in ENU, this is to simplify the gravity direction and to match easier with the IMU Factor examples from GTSAM. There are for sure ways to work in ECEF, but the ENU conversions are not so expensive, depends on your application of course.

Regards,

Radu

[Mike]

Thank you for the information,

I would like to understand your approach more, do you use a local reference frame for the whole factor graph or does ENU get updated between IMU factors? I'm very curious about the viability of incorporating IMU across an area big enough that using one reference point to define ENU may not work well enough.

Thank you

[Radu Cioaca]

I am using a reference position over the whole graph assuming that my scenarios are quite localized (within a few km max).

Going over longer distances where a fixed reference would not hold over the whole graph is an interesting topic to discuss. My first thought is to update the reference periodically and store the references over windows, this for sure would affect the whole optimization (jumps when you update)... If the graph is "chained" I guess the impact would not be so big and you could do more sub-graphs, one with its own reference.

The classical approach to define the state as ECEF/LLH, attitude to ENU, biases,.. etc I assume would require a "custom" IMU factor that "knows" to work with LLH and that attitude... that might not be very straightforward. I am interested in the topic, I will come back when I get more time to think about it.