Feature/se3 curve

[furgalep]

Hi all, I just wrote a quick and dirty SE3 curve interface.

@rdube @gawela @mikebosse @sanderson77 @HannesSommer The SE3 Evaluator should look like the VectorSpaceEvaluator but with functions to compute the specific "physically meaningful" derivatives as well.

Please check this commit carefully and make sure that the interface makes sense. In this regard, I'm open to suggestions. I went with a curve defined as T_a_b. Then I have

  /// \brief Evaluate the velocity of Frame b as seen from Frame a, expressed in Frame a.
  virtual Eigen::Vector3d evaluateLinearVelocityA(Time time) = 0;

  /// \brief Evaluate the velocity of Frame a as seen from Frame b, expressed in Frame b.
  virtual Eigen::Vector3d evaluateLinearVelocityB(Time time) = 0;

And so on for a few cases. I hope that is clear. If someone has a better interface/naming design, please discuss below!

Thank you!

[HannesSommer]

Whenever I start thinking about those functions I get the feeling that this should not be part of (a SE(3) ) curve code but of a separate toolkit, wrapping the necessary computations. Maybe we can at least have the (free) functions converting curve derivatives to physical kinematic quantities, depending on how the curve is used, in a separate utility files and have the curve member functions forward to them? The scope of Kindr would be perfect bu I'm afraid it isn't that far in terms of SE(3) :(. Ah, and don't we stick to middle age c++? Then we can't depend on Kindr either (it is c++11).

These curve member functions might be comfortable. But there is typically the problem that then the curves need to know/assume how they are used to model physics, which they don't as pure manifold curves (i.e. as purely mathematical objects).

[furgalep]

@HannesSommer, in principle, I agree but I think we should be pragmatic in this case.

You are right, we can't depend on Kindr, so we will roll our own. We could start the pure free-function version of Kindr to support this library. That would help a lot.

The main question this thread should answer is: what about this interface naming? Can anyone think of clear, unambiguous names for these quantities? Or is it just overall very difficult to get right and we should make sure the documentation is extremely clear?

@sanderson77 @timbarfoot

[furgalep]

One other option: we could have an SE3 curve (4x4 with 6x1 derivatives) and have derived classes with better names.

For example, we could have a class called Trajectory that explicitly models T_{world, body}, and has nice functions in that regard. This will probably be all we will use in the scanmatching project but it would serve as the model for how to make a nice interface for a particular type of SE3 curve.

[mikebosse]

I'll second that option!

though maybe calling the derived class a RigidBodyMotion.

then we have the functions evaluateVelocityInBodyFrame() and evaulateVelocityInWorldFrame() which return the appropriate 6x1 vector

or what would be a better name than World? Base? or Reference? or Fixed?

On Sun, Oct 5, 2014 at 6:41 PM, Paul Furgale notifications@github.com wrote:

One other option: we could have an SE3 curve (4x4 with 6x1 derivatives) and have derived classes with better names.

For example, we could have a class called Trajectory that explicitly models T_{world, body}, and has nice functions in that regard. This will probably be all we will use in the scanmatching project but it would serve as the model for how to make a nice interface for a particular type of SE3 curve.

— Reply to this email directly or view it on GitHub https://github.com/ethz-asl/curves/pull/32#issuecomment-57943532.

[sanderson77]

I also like this other option, and I think it can cover the majority of cases for roboticists.

With respect to Mike's open question about naming, I agree that "world" frame might be too specific.. the user can estimate the curve with respect to any fixed frame they choose.. I'm partial to Reference.

[HannesSommer]

Why not call the class RigidTransformationFromAtoB and then have members like evaulateVelocityOfBobservedInAexpressedInB() :) or something a bit more brief (employing some naming convention)? That would be quite universal and can still be made clear... It could be a wrapper for (or somehow associated to) any kind of SE(3) or SO(3)xR^3 curves.

[HannesSommer]

The specific meaning of A and B could be then part of the variable names.

[furgalep]

Here is another proposal:

RigidBodyMotion could have an enum that the user could redefine...

Vector6d getVelocity(Time time, int frameSeenMoving, int valueExpressedIn);

The two frames would be 0 and 1, and then people could

const int WORLD_FRAME = 0;
const int BODY_FRAME = 1;

Then it could be called like:

/// Get the velocity of the body, as seen from the world, expressed in the world.
Vector6d w_v_w_b = curve.getVelocity( time, BODY_FRAME, WORLD_FRAME);

This would allow the user to define the constants however they want.

[mikebosse]

That seems too complicated.

On Mon, Oct 6, 2014 at 5:50 PM, Paul Furgale notifications@github.com wrote:

Here is another proposal:

RigidBodyMotion could have an enum that the user could redefine...

Vector6d getVelocity(Time time, int frameSeenMoving, int valueExpressedIn);

The two frames would be 0 and 1, and then people could

const int WORLD_FRAME = 0; const int BODY_FRAME = 1;

Then it could be called like:

/// Get the velocity of the body, as seen from the world, expressed in the world.Vector6d w_v_w_b = getVelocity( time, BODY_FRAME, WORLD_FRAME);

This would allow the user to define the constants however they want.

— Reply to this email directly or view it on GitHub https://github.com/ethz-asl/curves/pull/32#issuecomment-58038246.

[furgalep]

This comes up when reviewing #40. I do like mike's idea, but I think it should be then that a Rigid Body Motion curve has two frames: fixed and moving T_fixed_moving.