Skip to content

Re Designing RBS and Tranforms in base types

Jump to bottom Edit New page
Javier Hidalgo edited this page Sep 16, 2015 · 6 revisions

Migration of the TranformWithUncertainty (TWU) from slam envire to base types.

  1. Move envire TWU to a more compact representation based on 6d axis+vector instead of matrix transform. 1a. create both base::Transform, base::TransformWithCovariance and the corresponding samples types (especially if we want to get rid of Pose). jakob: Note that base::Transform is a typedef for Eigen::Isometry3 (so a matrix), having Transform and TWU different seems not so good javi: actually base::Trasform is an Affine3d

  2. Add frame names. Probably with the same name source/target but with a proper meaning to allow kinematics chains/tree (useful for envire and manipulators)

    • For that, we can consider the choice of building a vector-based type instead of single types, especially if the goal is to represent kinematic trees. I.e. having a type modelled after base::samples::Joints, that contains a vector of sources, targets and transforms instead of placing the source/target in the transform itself.
    • having the frames embedded in the type sucks badly for things like trajectories (since, in this case, all points have the same source and target frames)
    • jakob: I fully agree here. I also prefer having the frame definition separate. But this smells like refactoring a lot.
    • sylvain: yes, it does. The point I am trying to make here is that if you want to try and phase out RBS we are refactoring a lot. Phasing out RBS is either going to be a lot of pain for a short period of time (get a proper migration path) or small pains for a long long time (just doing it)

  3. Having TWU we coud get rid of base/Pose and then TWU can be use by RBS to get the position and orientation. Methods setPose() and getPose() of RBS. It will make things easier in the future.

  4. Adapt the transformer to work with TWU and since point 3 is already in RBS it will be simpler since RBS getPose() could return a TWU and therefore being the method interface between RBS and transformer (using TWU as data-type). jakob: I think adapting the transformer is the least of the problems. sylvain: agreed

  5. Update documentation in rock-robotics.org

Each point can be a new pull request.

Open Questions

  • how do we deprecate RBS in the cases where Transform should be used, and Pose ? At the orogen level, we still can't make connections between separate types, which means that most device/components would have to accept and produce both RBS and Transform for a while. How long ? javi: to me the migration is the following. In case the existing component fill a whole RBS, then it should keep using RBS. In case the existing component is using RBS but only using the pose, then it should migrate to TWU. Regarding integration with the transformer, the bullet 4 written above should apply. sylvain: by doing so, you are envisioning a system where half the components (the RBS producers) won't be able to feed data to the other half (the TWU consumers)
  • what do we tell users ? Which type should they use in which condition (noting that one cannot connect a RBS port with a TWU port) javi: In case the component has a full state vector information to port out (i.e: velocity and angular velocity) then use a RBS. Otherwise, port out information using TWU. sylvain: you don't address the main issue. A RBS producer cannot feed data to a TWU consumer !

List of Actions.

  1. Keep Affine3d transformation. Isometry is more restrictive and changing in the future will not be that hard. Affine3d = isometry + scaling and/or shearing. It might be useful in the future to have Affine3d, but it is true that for RBS is not. Also, base::Transform3d is currently Eigen::Affine3d

  2. Compact vs Normal storage. Since we go for Affine3d we keep 4x4 matrix (Normal). It can be changed in the future without much pain since it is internal to the class (just logger pain).

  3. Change base::Pose, keep base::Pose2d. base::Pose will be:

typedef base::Pose base::TransformWithCovariance

  1. Make the old base::Pose as deprecated using macro from Deprecated.hpp.

  2. RBS getPose and setPose methods will return the new base::Pose

  3. RBS: Having a new manner for Pose by using TWU seems to be the right time to do the same for velocities (base::Twist) and accelerations(base::Wrench) instead of the current and separated definition. RBS will provide get/set methods to access 3d vectors (i.e.: linear velocities or angular velocities).

  1. base::TwistWithCovariance and base::TwistWitCovariance will also have uncertainties

  2. RBAcceleration will be affected by base::Wrench

  3. Twist and Wrench will propagate uncertainties as in: http://www.fas.harvard.edu/~scphys/nsta/error_propagation.pdf

Those are the first changes. We could stop here, and it is a good point to stop. Future changes might be transformer and frame names (sourceFrame and targetFrame) and whether to keep the source-target convention. Source-target is nice to transform sensory information but a pain for envire representation and/or kinematics chains.

  1. One solution would be reference_frame and target_frame or parent_frame and child_frame. The transformation always goes from reference_to_target or from parent_to_child

  2. Who said ROS is using source_to_target convention? http://wiki.ros.org/navigation/Tutorials/RobotSetup/TF

Add a custom footer
Add a custom sidebar

Clone this wiki locally