revise aero_std?

[sasabot]

possible fixes on next version?

• overall
  • fix time unit to seconds and add warnings for values too large
  • I think it is okay to assume a hand, upper body, lifter, and wheels, but the implementations should not be hard coded (parts not used should have a blank implementation and parameters should be brought from aero_shop. aero_std should be built at setup to avoid troubles).
  • getRobotStateVariables should return a const. I think there was a concept of "we no longer set angles outside the model" and that "the method should only be used for saving robot states"? @YoheiKakiuchi
• lifter
  • remove lifter_ik_, implementation should be inside setLifter
  • consider header implementations for setLifter, getLifter to avoid hard coding on specific type bool aero::interface::AeroMoveitInterface::setLifter(double _x, double _z) { return aero::lifter::set(_x, _z); } where aero::lifter::set is defined from a header copied at setup. (to be general and to avoid confusion with joints, input should be aero::Vector3)
• hand related
  • remove aero::eef options and add eef conversions instead to convert will require solving the I.K. anyways and is inefficient, there is no problem w/ kinetic so leave as is
  • remove sendGraspFast; so many problems with current hand, we should forget this until hand is stable done
  • consider header implementations for setHand, which allows multiple fingers template<typename... Targs> void aero::interface::AeroMoveitInterface::setHand(aero::arm _arm, Targs&&... _rads) { return aero::hand::set(_arm, {std::forward<Targs>(_rads)...}); } (note, setting finger one by one should use setJoint)
  • consider header implementations for getHand, double aero::interface::AeroMoveitInterface::getHand(aero::arm _arm, aero::hand::finger _place=aero::hand::finger::thumb) { return aero::hand::get(_arm, _place); }
  • is there a specific reason for sendModelAngles not sending the hand angles? is this common with other robots? I see disadvantages such as "did setHand for solving under collision but forgot to sendHand" but I don't see any advantages. @YoheiKakiuchi
• planning related
  • remove solveIKSequence, solveIKOneSequence, sendSequence, sendPickIK, sendPlaceIK, these should be done using moveit planner
  • add pick poses in header instead? aero::Transform aero::poses::top_grasp;
  • remove ObjectFeatures? markers should use planning scene, and adding sensor etc. should be in MoveitInterface?
• IKSettings.hh
  • add move group with arm + waist pitch?
  • do we need lifter_x, lifter_z in aero::joint? this doesn't work right? @YoheiKakiuchi
  • aero::joint, joint_map and string_map should be written in a auto-generated file
  • not sure about struct fullarm, there is no real method that can send an arm+hand structure at once (would be nice to have one though)

[YoheiKakiuchi]

consider header implementations for setLifter, getLifter to avoid hard coding on specific type bool aero::interface::AeroMoveitInterface::setLifter(double _x, double _z) { return aero::lifter::set(_x, _z); } where aero::lifter::set is defined from a header copied at setup. (to be general and to avoid confusion with joints, input should be aero::Vector3)

Currently, origin of arguments (_x, _z) for setLifter is waist position at initial pose. Then, we need height of initial position.

origin of arguments (_x, _z) for setLifter should be floor level or lifter origin. Because it does not require initial position and the same value can work with different lifter.

[sasabot]

I would say that's a valid solution. One concern is, it would be difficult to code something like "go to the highest position" which would be "setLifter(0, 0)" with the current code. we would still need some variable we can refer to as the highest position e.g. aero::lifter::max_z.

[sasabot]

another thing is, the function should be abstract anyways, because we have no guarantee that the lifter will always stay two dimensional. (for example, aero-four-legs had a completely different kinematic structure, three dimensional, and was a different implementation)

[sasabot]

@YoheiKakiuchi edited my first comment where I would like to hear your suggestions. thanks.