Feat/Pitch Roll Estimator #314
Conversation
…oJackets/roboracing-software into feat-302/pitch-roll-estimate
| quat_tf -= initial_axes; | ||
|
|
||
| // Convert back | ||
| cam_geom_.GetCameraPose().orientation = tf2::toMsg(quat_tf); |
There was a problem hiding this comment.
GetCameraPose returns a Pose by value, so I would be surprised if line 97 actually changes the internal state of cam_geom_
| if (!axes_init) { | ||
| // Set the initial axes | ||
| tf2::convert(cam_geom_.GetCameraPose().orientation, initial_axes); | ||
| } |
There was a problem hiding this comment.
Does this assume that the car is upright and flat when the node is launched? That's fine as long as it's documented
|
I think this class in a ROS package does the 3D geometry stuff right, but like my CameraGeometry class, it only updates through TF which might be too slow for "real-time" reactions to our pitch and roll. http://docs.ros.org/melodic/api/image_geometry/html/c++/classimage__geometry_1_1PinholeCameraModel.html Here is my recommendation: fix CameraGeometry so that a user can change its orientation and/or pose, but continue to ignore the roll dimension in ProjectToWorld. I would expect more of our present error to come from ignoring pitch than from ignoring roll. Then proper 3D point projection (simplified raycasting) can be added in later if it's still needed |
|
Going to close this for now (a bit stale) and link it in the issue. |
Closes #302
Adds functionality to improve our pointcloud projector. Uses the IMU to read in the axes and updates the camera pose to reflect the rotation of the chassis (pitch and roll primarily due to the suspension moving). These updates are propagated through the pointcloud projector.