Revision history [back]

Can the occasional good estimate of the position come in to the package's ekf node via an odom message? Or does this node require a more regular position like a normal message from a wheel odometer source?

It depends on the quality and frequency of the pose data. The real challenge is going to be using the IMU data. We don't have bias estimation in the filter for IMUs, so the accelerations will rapidly integrate into non-trivial velocities. The pose updates will limit the effect of this, but my experience has been that just pose + IMU is not a great use case. YMMV.

Or, should the occasional good estimate of position go to the navsat node provided by the robot_localization package which handles occasional position updates like a gps would provide. The navsat node then feeds ekf filter node via odom messages. Are these odom messages from the navsat node continuous, or do you get just one for each occasional good position estimate.

No reason to bring navsat_transform_node into the picture. It would just end up sending pose data to the EKF at the same frequency as the sensor.

Another issue to think about is since the hand can move freely in 3d space, the orientation of the imu will not be a clue to its heading. However, the imu linear acceleration values will indicate the heading. Can the ekf node use these values directly to deduce heading, or does heading need to be calculated before feeding the ekf node?

The latter. The filter doesn't do anything especially clever with sensor inputs, other than limiting which ones get fused, and things like coordinate transformations. If you want to infer some new bit of orientation data from the accelerometers, you can either write a new node, or modify your IMU driver to put that data into the orientation fields.