If i have a 9-dof imu, how can I set the init rotation?

[Huguet57]

Hi! This is an interesting one. I am working on the same thing in the hdmaps branch but it's not ready for release yet (in a couple of days it will be).

Basically what you would want to do is initialize the Localizator instead of with the identity matrix, with the rotation given by the magnetometer.

I will try to do a pull request with a quick fix for now, see if it could work out for this case before the hdmaps functionality is officially released.

[Huguet57]

@qpc001, check this pull request, see if this is what you were looking for. Own "Xaloc" dataset has a 9-DOF IMU.

[qpc001]

@Huguet57 commit [6888edef8a83462a5a41b124c7360a8c8a2b227e] is not complete for using the orientation of IMU. Because it need to handle about the [compensate] module and Localizator::latest_state() function.

[Huguet57]

Mmm so you don't only want to set initial orientation, you want orientation as input to the Localizator and Compensator. Is that right?

[qpc001]

no, I mean [6888edef8a83462a5a41b124c7360a8c8a2b227e] not work rightly.

[Huguet57]

Can you explain more in depth what it is that you mean? Right now, what it does is it sets as initial rotation the first IMU's orientation.

[qpc001]

你能更深入地解释你的意思吗？现在，它所做的是将第一个 IMU 的方向设置为初始旋转。

emmm, [6888edef8a83462a5a41b124c7360a8c8a2b227e] only set the initial state of Localizator, but Localizator::latest_state() function will return a null State when the first run. On the other hand, [compensate] module also need the initial state of Localizator, but it just create a null State in Accumulator::get_prev_state function, calling by the Compensator::path.

[Huguet57]

I see what you mean now. It is true that now it makes a jump from null to initialized that could be avoided.

I will get into it.

[qpc001]

我明白你现在的意思了。确实，现在它可以避免从 null 到 initialized 的跳转。

我会进入它。

for more test, I think commit [08c7093cc7212106a996f60ee5f4691d20e3f7f0] is better than branch [main]. I mean , the accuracy and fluency.

[Huguet57]

is better than branch [main]. I mean , the accuracy and fluency.

Since commit [08c7093cc7212106a996f60ee5f4691d20e3f7f0] only time management has changed, for the better (in principle). Would you say the same about commit [81de64ce86a27c53930bb2b9ce4270f3531b92bb] (before the 9-dof initialization commit)?

the accuracy

Accuracy you mean poses accuracy or map quality?

and fluency

Fluency you mean the readability of the code or that it doesn't make the jump from null to initialized?

[qpc001]

优于分支 [main]。我的意思是，准确性和流畅性。

自提交 [ 08c7093 ] 以来，只有时间管理发生了变化，变得更好（原则上）。您对提交 [ 81de64c ] （在 9-dof 初始化提交之前）也会这么说吗？

准确度

准确度是指姿势准确度还是地图质量？

和流畅

流畅性是指代码的可读性还是它不会从 null 跳转到初始化？

accuracy: means [main]'s poses result are drift more than [08c7093cc7212106a996f60ee5f4691d20e3f7f0]

fluency: means that [08c7093cc7212106a996f60ee5f4691d20e3f7f0]'s lidar process FPS is higher than [main]

[Huguet57]

This is interesting... :eyes: Do you use real_time: false? Also, do you use the Heuristic or wihout Heuristic (last part of YAML config file)?

poses result are drift more than [08c7093]

If you run the same bag 5 times in a row does it always perform worse? How much worse are we talking about?

lidar process FPS is higher than [main]

How much higher? 10Hz vs 9Hz or 10Hz vs 200Hz? Is it really significant?

[Huguet57]

Hey, I finally managed to fix this at commit 74d13e207ab2f5bd38951a9542bff6560d847dea. Check it out!