Arcore-android-sdk: Motion tracking coordinates system

[npal1008]

Hi,
I would like to use the motion tracking capabilities of arcore as a source of odometry for a robotic application. I wrote a simple android app that streams the current pose estimate of arcore to draw a path, but now I have a problem: since the World Coordinate Space of arcore changes frequently I observe sudden jumps in the path (sometimes 10cm and sometimes up to 1.2m).
Is there a way to get the pose with reference to a fixed coordinate space or maybe to know when and how it changes, in order to correct the "jump"?

Thank you in advance

[manuelloit]

Hi.
It's a very interesting question; I have a similar problem.
Can anyone please solve that problem or indicate how to solve it?
Thanks.
Manuel

[inio]

Anchors are your best bet. Create anchors frequently and measure motion relative to the previous anchor.

For navigation in a fixed environment, also consider using cloud anchors for continuous relocalization and keep an eye on #94.

[npal1008]

Thanks!
If possible I have two questions:

• How can I measure a pose relative to an anchor?
• If I create new anchors, and then I detach the old ones how can I measure the motion from the first anchor, assuming that it is the origin?

Sorry if this questions seems stupid but I'm quite new to arcore

[inio]

Sorry, this fell through the cracks.

How can I measure a pose relative to an anchor?

The pose of an anchor (or camera, or just about any other pose returned from or taken by ARCore) is a translation to world space world_T_anchor. If we have two such poses, we can compute the inverse of one and compose to get the transform from one anchor to another or to the camera: wTa1^-1 * wTa2 = a1Tw * wTa2 = a1Ta2, or in code anchor1.getPose().inverse().compose(anchor2.getPose())

If I create new anchors, and then I detach the old ones how can I measure the motion from the first anchor, assuming that it is the origin?

That will suffer the same drift and jumps as just tracking relative to the first anchor. The issue is that under the hood we have three motion tracking systems:

1. IMU integration, running at update() rate but subject to rapid divergence due to double integration of accelerometer data.
2. VIO (Visual-Inertial Odometry), updating many times per second, constraining the runaway velocity from IMU integration but only providing relative motion, so drift can still accumulate rapidly.
3. SLAM (Simultaneous Localization And Mapping), which updates about once per second and provides the real smarts of the system making anchors actually stick in place.

The jumps you're seeing are probably the SLAM updates as loop-closures are detected and the map updates substantially. I'm not sure how to avoid them besides working off a previously built map (requested in #94).

[inio]

Closing for inactivity.

[EbadSyed]

@inio

It would be really great if we had the ability to turn off SLAM and Loop Closures, I know it is required for Sticking Anchors in a Place but can be a nuisance for log term Robotics Applications.

[npal1008]

It would be absolutely great!

[manuelloit]

I'd need it too; it would be really a very important thing

[inio]

@EbadSyed @npal1008 @manuelloit You can approximate this by creating an anchor every frame and accumulating the relative motion over short time deltas. When there's a SLAM update the relative motion over the last ~1 second should change very little if at all.