dataset without weights

[hrheydarian]

Hi,

Would it be possible to sync SE relative parameters for which there is no weighting coefficients for edges? Or what should we set for the weights in case we do not have these information?

Actually, I tried a bit to understand how these weights (measurement.kappa and measurement.tau) are computed (eq. 11 in the long report) and why there are separate weights for rotation and translation but unfortunately I could not figure it out. Could you please tell me if these weights are computed or they are obtained during acquisition?

Thanks

[david-m-rosen]

Hi Hamidreza,

Kappa and tau are precision parameters that describe the uncertainty in the rotational and translational components of each relative measurement x_ij = (t_ij, R_ij), i.e., they are part of the description of the measurement model that is assumed to have generated the data x_ij (cf. equation (10) in the tech report). You should think of these values as being obtained as part of the measurement acquisition process, as they essentially encode how accurate the sensor is that was used to generate each observation.

In principle, every real-world measurement should have some such kappa and tau associated with it (since it does have some degree of uncertainty), and so SE-Sync does require that these values be specified. If you do not know what the uncertainty of each of your measurements is (and you suspect that they should all be "similarly" accurate), you can weight (intuitively, "trust") each of them equally by using the same values of kappa and tau for all of them -- in that case, the values of kappa and tau serve to trade off the "cost" of the rotational and translational components of the error, and you can choose them such that, for example, 1 degree of angular error costs about as much as e.g. 1 cm of translational error.

[jlblancoc]

Hi @david-m-rosen,

Something you said made me recall a theoretical “detail” that annoys me, so I wanted to take the opportunity to learn your opinion on it. But first things first: congratulations for your huge contributions to the theory of SLAM, and for releasing open-source implementations.

The point is related to:

you can choose them such that, for example, 1 degree of angular error costs about as much as e.g. 1 cm of translational error.

Recently I found some old (<1985 !!) references by, also, an MIT researcher, who said (See [1,2,3] ):

"there is no natural positive definite metric on SE(3)".

And the worst part is... I think he was right.

Any metric that gives different closest SE(3) poses depending on our arbitrary choice of translation units (cm, mm, meters,…) makes me feel really uncomfortable.

Probably that’s how things are and we must live with that, and focus on practical scale tuning as engineers, but I was just curious about what do you (and anyone else interested? @jbriales ) think about this weakness of any SE(3) metric.

Best,

• [1] Loncaric, J. (1985). Geometrical analysis of compliant mechanisms in robotics (euclidean group, elastic systems, generalized springs. PhD. PDF
• [2] Brockett, R., & Loncaric, J. (1986). The geometry of compliance programming. Theory and Applications of Nonlinear Control Systems, 35-42.
• [3] Loncaric, J. (1987). Normal forms of stiffness and compliance matrices. IEEE Journal on Robotics and Automation, 3(6), 567-572. PDF

[david-m-rosen]

Hi @jlblancoc,

Thanks for your very kind note :-). (And apologies for the long delay in getting back to you -- I've been feeling a bit under the weather this past week, and I wanted to be able to think clearly before I responded :-P.)

As a prelude, let me just mention that if you're at all interested in sharp statements regarding possible metrics on SE(3), Zefran, Kumar and Croke have a really nice paper in which they provide a classification of two families of metrics satisfying two different criteria that might be deemed basic "reasonableness" requirements in robotics applications (in the first case, metrics that induce screw motions as geodesics, and in the second case, metrics whose covariant derivatives correspond to physically-correct accelerations). This is one of the best expositions of the relevant differential-geometric issues as they relate to robotics that I've seen -- would definitely recommend if you're interested in really drilling down into the details ;-).

Now, to your question: I definitely agree with you that the seemingly arbitrary choice among metrics is (at first glance) troubling, and that we ought to be able to come up with more principled ways of selecting one than arbitrary parameter tuning. The good news is that I think in practice there are often pretty natural ways of doing this.

To see this, I think it helps to consider the even simpler case of R^n: it's a straightforward exercise to show that any positive definite matrix M induces an inner product (metric) on R^n according to <x, y> = y' M x, and that every inner product on R^n corresponds to some such matrix (to see this, simply fix a basis B and then show that you can express the inner product between arbitrary x and y as a linear combination of inner products among the basis vectors, which become the elements of M when expressed in the basis B). So in fact, plain old R^n itself already has an infinitude of possible metrics to choose from, and there's no a priori reason to pick any one of these over any other (yes, it's even worse than you thought ;-P!)

The key observation here is that (fortunately) we are typically not trying to decide upon a distinguished metric a priori; at least in robotics anyway, we are generally considering questions like this in the context of some particular problem/application we are trying to address, and this additional contextual information is often sufficient to pick out at least a restricted class of metrics, and very often a unique one. To continue the analogy with R^n, while there might not be any a priori reason to prefer one inner product over another in the abstract, there are certainly obvious conditions that I would want to impose as soon as I place an interpretation on this space in the context of my actual problem. For example, if I am using R^n to represent points in physical space, I would almost certainly want to choose a rotationally-invariant inner product, to capture the fact that physical space has no "preferred" orientation. On the other hand, if I'm thinking of the elements of a particular vector as e.g. samples from a joint Gaussian distribution, then a rotationally-invariant inner product could be totally inappropriate, as some directions/orientations in my space really will be wildly more uncertain than others, and it's important that I have a notion of similarity that captures this fact.

To bring this back to the case of SE(3): consider, for example, that the original formulation of the problem that SE-Sync solves is actually a maximum-likelihood estimation under an assumed generative model for the data -- the quadratic loss function that appears throughout the majority of the paper is actually an entirely mechanical consequence of the measurement model assumed in (10). The important thing to recognize about this is that, strictly speaking, this is not something that one is free to choose: while in practice one does have a bit of modeling leeway, in principle this is simply a description of the operating characteristics of a physical device, i.e., this is entirely determined by Nature.

So in general, my takeaway here is that often the seeming arbitrariness in selecting a suitable figure of merit for a particular application can be alleviated by coming up with a suitably sharp characterization of what exactly it is that one is trying to achieve -- which I think is always an incredibly useful exercise, even independent of the question of metrics ;-).

[jlblancoc]

Thanks a lot, @david-m-rosen for the feedback! I'll add the paper you mentioned to my personal list/stack of papers to read ;-) Cheers.

[hrheydarian]

Hi Hamidreza,

Kappa and tau are precision parameters that describe the uncertainty in the rotational and translational components of each relative measurement x_ij = (t_ij, R_ij), i.e., they are part of the description of the measurement model that is assumed to have generated the data x_ij (cf. equation (10) in the tech report). You should think of these values as being obtained as part of the measurement acquisition process, as they essentially encode how accurate the sensor is that was used to generate each observation.

In principle, every real-world measurement should have some such kappa and tau associated with it (since it does have some degree of uncertainty), and so SE-Sync does require that these values be specified. If you do not know what the uncertainty of each of your measurements is (and you suspect that they should all be "similarly" accurate), you can weight (intuitively, "trust") each of them equally by using the same values of kappa and tau for all of them -- in that case, the values of kappa and tau serve to trade off the "cost" of the rotational and translational components of the error, and you can choose them such that, for example, 1 degree of angular error costs about as much as e.g. 1 cm of translational error.

Thanks David for your great explanation here and also on the other thread.