Revision history [back]

You don't need a compass for r_l. You just need a compass for integrating GPS data. If you are just driving around on a wall, there's no need for that.

I don't really see that your use case is that different. It's no different than, say, an aerial vehicle flying straight up. r_l is a 3D state estimation package, so moving around the Z axis is fine. I'm not sure I would "pretend" to be in the X-Y plane for this problem. If your IMU says you're climbing a wall, then just fuse that into the EKF. Your EKF yaw angle will remain fixed the entire time, because the wall has a fixed world-frame Z axis orientation. Roll and pitch will move around as the robot drives, but those are absolute angles, so none of your angles should drift, provided that you fuse roll, pitch, and yaw, and not just their velocities.

The only caveat is that r_l uses Euler angles internally, so you may have some trouble if the noise in the measurements sends you through +/- 90 degrees on pitch (or if the wall isn't perfectly flat). YMMV.

An alternative, though I haven't though through if this would work, would be to define a transform for your base_link frame to the imu frame that captures the vertical orientation of the IMU. Then, turn on two_d_mode and see what happens. I honestly haven't thought about this hard enough, so I'm not positive it'll work. This would be effectively pretending you are in the X-Y plane.