Solve unit vector

[Andy Keeling]

Is there a way to constrain a parameter block to unit magnitude?

I have a unit 3d vector whose direction needs to be solved. The cost function has readings of magnitude along the vector for multiple observations and I wish to solve for the direction of the vector, and the magnitude (I have many observations for each magnitude).

All I can think is to create an arbitrary vector such as 1,0,0 and feed in my initial guess at the real vector position, then calculate a quaternion rotation to bring my x=1 Vector into line with the initial guess. Then use the quaternion plus another value (magnitude) in the cost function. Then after solving, convert the quaternion back into the actual vector (which will be perpendicular to the quaternion axis of rotation)

This seems long winded so I was hoping I could have a vector parameter block (x,y,z) with a constraint that magnitude equals 1?

Could I use axis-angle but just treat it differently in my cost function (use the direction for my linear motion, and the magnitude as the distance along the axis rather than the rotation around it). I am not sure Ceres will let me have any magnitude though, since in normal use only 0 to 2pi makes sense.

I am new to Ceres so any advice greatly received!

[Sameer Agarwal]

http://www.ceres-solver.org/nnls_modeling.html?highlight=rotation#_CPPv2N5ceres33HomogeneousVectorParameterizationE

is your friend.

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/f142695d-1c18-4db7-a293-6cc12b022f54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Keeling]

Ah! Brilliant!

Can I assume that I can constrain (fix) the last number as 1, so that my vector is always xyz1 ?

On Tuesday, 26 June 2018 20:55:54 UTC+1, Sameer Agarwal wrote:

http://www.ceres-solver.org/nnls_modeling.html?highlight=rotation#_CPPv2N5ceres33HomogeneousVectorParameterizationE

is your friend.

On Tue, Jun 26, 2018 at 12:26 PM, Andy Keeling <dr.a.k...@gmail.com> wrote:

Is there a way to constrain a parameter block to unit magnitude?

I have a unit 3d vector whose direction needs to be solved. The cost function has readings of magnitude along the vector for multiple observations and I wish to solve for the direction of the vector, and the magnitude (I have many observations for each magnitude).

All I can think is to create an arbitrary vector such as 1,0,0 and feed in my initial guess at the real vector position, then calculate a quaternion rotation to bring my x=1 Vector into line with the initial guess. Then use the quaternion plus another value (magnitude) in the cost function. Then after solving, convert the quaternion back into the actual vector (which will be perpendicular to the quaternion axis of rotation)

This seems long winded so I was hoping I could have a vector parameter block (x,y,z) with a constraint that magnitude equals 1?

Could I use axis-angle but just treat it differently in my cost function (use the direction for my linear motion, and the magnitude as the distance along the axis rather than the rotation around it). I am not sure Ceres will let me have any magnitude though, since in normal use only 0 to 2pi makes sense.

I am new to Ceres so any advice greatly received!

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.

[Andy Keeling]

To answer my own (dumb) question, I should simply use the eventual fourth parameter (w) as the magnitude, and divide xyz by this whenever I need to use the unit vector.

Thanks - I'll give this a go.

[Sameer Agarwal]

you can do that too.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/3ac4a7f0-5d77-4811-b09b-e56835ea5553%40googlegroups.com.

[Andy Keeling]

Actually, there may be a slight issue here.....

The direction of the vector never changes (but must be solved for).

However, I have thousands of observations, in groups, so eg 100 observations with magnitude approximately=10 (but needing refining), then another 100 observations with magnitude approximately=20 (but again, to be refined by Ceres).

So the unit vector should only be solved once over all the thousands of observations, but the magnitude will have more solutions.

I could simply pass in the xyzw homogenous vector and a separate scaling factor, S. In the cost function I would always divide xyzw by w, then multiply by S. That way, xyzw can (and should) have one solution over all the thousands of observations, but I may have,say, 10 or 20 solutions for scale, from my different blocks of observations.

This should work, but is a touch messy. I'm guessing there is no way to tell Ceres to optimize 'xyz' over all the 1000's of observations, but solve 'w' in separate blocks ?

[Sameer Agarwal]

Andy, why are you not using just a 3d vector with a homogeneous parameterization to get the direction?

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/e025b4f5-215c-4646-a527-3797bad16fa0%40googlegroups.com.

[Andy Keeling]

My assumption was that I have to pass in an array of 4 values for a 3d homogeneous vector. So my initial guess to Ceres would be xyz1. But then I presume that as Ceres optimises it, the 4th term could become any value, and it will be down to me to divide everything by w to go back to the 3- vector.

This is fine except I would also have to do this in the cost function, so as much as Ceres changes w, the reprojection error will not change (ie w has no effect) and I thought this might confuse Ceres or be unstable.

Are you saying I can just pass in an array of 3 values and set parameterisation to homogenous. Then Ceres internally makes a 4-value copy and handles it appropriately ?

[Andy Keeling]

As an update to this.

I implemented the following a cost function that takes in an array of 4 values in one block (My unit xyz1 homogenous vector), and a scale value in another block (how far the object had moved along that vector for that particular obsrrvation).

In calculating the residual I divide each of x,y and z by the fourth vector value (w) to use it as a normal unit vector with my scale factor.

After solving, the caller code also divides the solved vector by its 4th component to get back to a unit xyz (now hopefully reoriented correctly)

Broadly this works but the final xyz (after dividing by w) is not quite a unit vector any more. E.g. some terms might be x=1.000004 etc.

Is this expected behaviour with doubles ?

Does Ceres vector parameterisation not enforce unit length?

Thanks

[Dmitriy Korchemkin]

> Does Ceres vector parameterisation not enforce unit length?

Note that HomogeneousVectorParameterization keeps the whole norm (x^2+y^2+z^2+w^2 in the case of 3-dimensional projective space) constant.

I suppose that you need to try HomogeneousVectorParameterization(3) for your parameter block of 3-dimensional unit vector, as Sameer proposed earlier.

[Andy Keeling]

Thanks Dimitriy

I guess I'm getting confused by the docs. As you say, a normal 3d Euclidean vector is represented as 4d in homogeneous coordinates.

But I can bypass this by just using a 3 unit (Ceres might think it is a 2d homogenous vector, but my cost function will treat it as a 3d vector of constant length).

I'll give it a go!

[Sameer Agarwal]

Andy,

Sorry for the delay in replying. I have been traveling. My original reply was confusing and I apologize for that.

HomogenousVectorParameterization is not the solution for you. Since it treats one coordinate differently than the others.

The simplest thing you can do, if you are only interested in optimizing the direction and not the magnitude of a 3-vector is to

parameterize your problem with a parameter block of size 3, and you normalize it before using it in your cost function. And when the solver returns, you normalize the value of the parameter block and thats your direction.

There maybe a minor problem here depending on your optimization problem is that if the norm of the vector becomes zero, then the normalization operation will fail.

Another thing you can do is to parameterize your problem as the 2-vector (theta, phi) and convert them into a unit vector on the sphere. Indeed you can use a three vector, which is the magnitude of the vector r, and set it to be constant when you are only optimizing over the direction and then hold the direction constant and only optimize the magnitude as needed.

Last thing you can do is to create a localparameterization which for a point x, ignores any contributions along its own direction .. i.e. only moves along the tangent space of the sphere. This requires a bit more work, but has no problems with singularities or numerical collapse.

Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/3ba17509-7aac-4850-9534-20f4aa076a70%40googlegroups.com.

[phreak...@gmail.com]

On Friday, June 29, 2018 at 10:51:56 AM UTC-3, Sameer Agarwal wrote:

Andy,

Sorry for the delay in replying. I have been traveling. My original reply was confusing and I apologize for that.

HomogenousVectorParameterization is not the solution for you. Since it treats one coordinate differently than the others.

Hi, sorry for intruding in the thread, but I'm using this parametrization to optimize a gravity direction vector (with a known magnitude which I assume constant). I'm currently

assuming that this parametrization restricts the vector inside the unit sphere. Is this correct? I'm not sure what you meant by your last sentence. 

[Sameer Agarwal]

On Thu, Jul 19, 2018 at 5:26 PM <phreak...@gmail.com> wrote:

On Friday, June 29, 2018 at 10:51:56 AM UTC-3, Sameer Agarwal wrote:

Andy,

Sorry for the delay in replying. I have been traveling. My original reply was confusing and I apologize for that.

HomogenousVectorParameterization is not the solution for you. Since it treats one coordinate differently than the others.

Hi, sorry for intruding in the thread, but I'm using this parametrization to optimize a gravity direction vector (with a known magnitude which I assume constant). I'm currently

assuming that this parametrization restricts the vector inside the unit sphere. Is this correct? I'm not sure what you meant by your last sentence. 

Okay so I went back and stared at the code some more. +Mike Vitus can correct me, since he is the original author of the code, but 

the homogenous vector parameterization should actually work fine for vectors on the sphere too. I.e. the parameterization is norm preserving.

If my reading of the code is right, then I think the documentation for this parameterization can use some work.

Sameer

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/c860cf14-d2d8-4c1e-9a13-8c5cd1595a82%40googlegroups.com.

[Mike Vitus]

Yes, the homogeneous vector parameterization preserves the norm of x.  

I can update the documentation to be more explicit.

Mike

[Sameer Agarwal]

Thanks Mike, can you take a pass at the code and the web docs ?

To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/ea57b319-d900-4d73-a4af-0c5dc010179b%40googlegroups.com.

[Jorgen Birkler]

Does it really work when the norm of the size-1 vector is zero?

For those looking at keeping a direction unit length, perhaps have the update be a 3 vector too;

https://github.com/jvlmdr/low-rank-nrsfm/blob/master/src/unit-vector-parameterization.cpp

[Dmitriy Korchemkin]

The problem with your parameterization (and any parameterization with the dimension of dx equal to the dimension of x) is non-trivial nullspace of Jacobian.

For example, for your parameterization, delta = (x_1, ... x_n) is a basis of 1-dim nullspace.

Rank-deficiency of jacobian of local parameterization results into rank deficiency of Hessian approximation.