ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Localizing on a vertical plane

asked 2017-12-07 03:14:41 -0600

rhas gravatar image

updated 2017-12-07 05:36:08 -0600

I am currently working on a mobile robot that is able to drive on a vertical surface. As it is a mobile robot i would like to be able to locate the robot continuously. From what i have gathered the two most common ways are either robot_pose_ekf or robot_localization. I haven't been able to find much material on robot_localization so for now I am looking at robot_pose_ekf. In the documentation it states that:

"The Roll and Pitch angles are interpreted as absolute angles (because an IMU sensor has a gravity reference), and the Yaw angle is interpreted as a relative angle.

Because I am trying to locate on a vertical plane this is exactly the condition i would like to exploit. Say that my map is represented in the XY-plane in Rviz (even though it is the physical XZ-plane) my absolute angle will be the Z-angle and this would enable me to have a absolute (non-drift) heading of my robot. Depending on the configuration of the robot the X or Y angles might line up with the gravity vector, I don't know if this could cause any trouble.

I have tried to see if there is a way to bend robot_pose_ekf into compliance, be it rotating the odometry of my robot into another plane to match up with the IMU or vice versa. But the problem I keep running into is that robot_pose_ekf has one relative angle and two absolute where i have at worst the same but depending on configuration a might have three absolute. furthermore as far as I have read robot_pose_ekf neglects the odom.pose.pose.position.x and odom.twist.twist.linear.z which inhibits me in rotating the whole system into the physical plane.

It might also be cause for trouble that the gravity vector no longer is on a specified axis as it can rotate as the robot rotates around the Z-axis.

The question: Is there a way to make robot_pose_ekf compliant with my configuration, that I just can't seem to figure out? Maybe it can be modified to neglect X and Y instead of Z and then just use Z alone?

OR

Maybe this is a job for robot_localization, I just haven't been able to find much information on this.

Any suggestions are MUCH appreciated, as I have set this as a (significant) milestone i my Bachelors project and I am running low on time.

EDIT: This definitely seems like a job for robot_localization, although in this talk it states that it is required to have compass readings, but i can't see why this is necessary, and it is definitely not an option as the robot I am working on relies on (very) powerful magnets to 'stick' to the vertical surface. Shouldn't the fused orientation the IMU is sending out be enough to give a heading? I am using a BNO 055 IMU.

Even though I am closer to a solution I am by no means there ... (more)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-01-26 02:55:08 -0600

Tom Moore gravatar image

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.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2017-12-07 03:14:41 -0600

Seen: 430 times

Last updated: Jan 26 '18