develop State Estimation message passing for Valkyrie about oh-distro

[gizatt]

Few questions:

• Are NASA_CORE_ROBOT_STATE and CORE_ROBOT_STATE the same? If so, is there a reason to keep NASA_CORE_ROBOT_STATE around?
• Are FORCE_TORQUE and NASA_FORCE_TORQUE the same? (same followup)
• Should the val driver generate POSE_BDI, even if it's just a (bad) guess?
• How is MICROSTRAIN_INS populated? (Pick a particular INS arbitrarily?)

[mauricefallon]

In order:

• I was going to get rid of CORE_ROBOT_STATE as all other signals from NASA are called NASA_*****. But I could aso just leave out the NASA_ instead. What's your vote?
• Same response
• POSE_BDI is currently its needed by Pronto (long story). Actually its just the orientation that's needed. I really need to do this. But I can assemble that from the orientation estimate that is in the pelvis IMU message.
  • For now lets publish the orientation from pelvisRearImu as POSE_PELVISREARIMU
• No, lets publish all available INS sensors for now and fix it up in the cfg file: NASA_INS_pelvisRearImu, NASA_INS_torsoRightImu
  Perhaps we should go by NASA_IMU_ as well

Mode 4 has some inaccuracies - libreoffice isn't the best for that. I'll revise this and remove some cruft

[gizatt]

• Keeping them all NASA_ prepended is fine with me / makes sense... as long as we don't eventually end up requiring other robot drivers (like the Atlas driver) to publish such-named messages to. It makes sense to publish those-named messages from the Val driver to indicate that they're Valkyrie-specific (unless one day we support a new NASA robot). Are you envisioning these channels being Val-specific?

The rest sounds good.

[mauricefallon]

as long as we don't eventually end up requiring other robot drivers (like the Atlas
driver) to publish such-named messages to

The Atlas driver publishes only messages beginning ATLAS_**** so its clear what comes from the robot.

We could use VAL_*, I chose NASA to distingush from confusing with any signals from IHMC. VAL would make more sense.

[gizatt]

Agreed on using VAL_*

[mauricefallon]

Ok, Lets go with:

• VAL_CORE_ROBOT_STATE ... joint_states, does not include multisense joint currently
• VAL_IMU_pelvisRearImu .... i.e. renaming the INS to IMU
• VAL_FORCE_TORQUE
• VAL_COMMAND ... NASA's diagnostic feedback of commands
• ROBOT_COMMAND ... Drake's control commands to the robot

[gizatt]

SGTM. To be complete, message types, for now, are:

• VAL_CORE_ROBOT_STATE: pronto::joint_states_t
• VAL_IMU_*: mav::ins_t
• VAL_FORCE_TORQUE: drc or pronto::six_axis_force_torque_array_t
• VAL_COMMAND_FEEDBACK: this is currently a pronto::joint_angles_t... which is perfect for this message in everything except the message type's name. I don't feel a huge need to change this unless you want it to be?
• ROBOT_COMMAND: currently drc::atlas_command_t, TBD as controller comes online.
  Are these good?

[mauricefallon]

Don't use pronto types in the translator - use the identical drc type. (I'd like to make a drc::ins_t message for that reason.). Pronto lcmtypes should be restricted to Pronto.
Where an LCM message type's contents are equivalent, the lcm pub/sub knows no difference - so pronto::joint_angles_t can be transmitted and drc::joint_angles_t received.

VAL_COMMAND contains the a ROS joint_state msg - hence the use of a joint message. Maybe this should be VAL_COMMAND_FEEDBACK

[mauricefallon]

I think this is resolved and summarised here:
https://github.com/openhumanoids/oh-distro/wiki/State-Estimation-Messaging
which I will update later