The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
For anyone looking here for a really nice way to debug the controller... Sorry, I've got nothing for you. Here's what I ended up doing.
Our global position data was provided by ORB VSLAM 2, and it was good enough to be fused directly with IMU and wheel odometry data in robot_localization and used as both our global positioning and local positioning provider. We set up a constant zero transform from map -> odom and pointed robot_localization at odom -> base_link. By doing this, we could see from the global frame everything that was going on in the local frame, because there was no difference. This allowed us to figure out what was causing the controller to act so erratically.
Basically, our localization was awful because of a weird orientation glitch (and because I know what you're all thinking, no, it was not related to incorrect quaternion math. Probably). Because of this, it was subject to error of +- 0.25 meters. That was the core of the issue, but fusing in IMU as Steve recommended was also necessary before we started to see decent results when navigating in any scenario except a straight line.
| | 2 | No.2 Revision |
For anyone looking here for a really nice way to debug the controller... Sorry, I've got nothing for you. Here's what I ended up doing.
Our global position data was provided by ORB VSLAM 2, and it was good enough to be fused directly with IMU and wheel odometry data in robot_localization and used as both our global positioning and local positioning provider. We set up a constant static zero transform from map -> odom and pointed robot_localization at odom -> base_link. By doing this, we could see from the global frame everything that was going on in the local frame, because there was no difference. This allowed us to figure out what was causing the controller to act so erratically.
Basically, our localization was awful because of a weird orientation glitch (and because I know what you're all thinking, no, it was not related to incorrect quaternion math. Probably). Because of this, it was subject to error of +- 0.25 meters. That was the core of the issue, but fusing in IMU as Steve recommended was also necessary before we started to see decent results when navigating in any scenario except a straight line.
| | 3 | No.3 Revision |
For anyone looking here for a really nice way to debug the controller... Sorry, I've got nothing for you. Here's what I ended up doing.
Our global position data was provided by ORB VSLAM 2, and it was good enough to be fused directly with IMU and wheel odometry data in robot_localization and used as both our global positioning and local positioning provider. We set up a static zero transform from map -> odom and pointed robot_localization at odom -> base_link. By doing this, we could see from the global frame everything that was going on in the local frame, because there was no difference. This allowed us to figure out what was causing the controller to act so erratically.
Basically, our localization was awful because of a weird orientation glitch (and because I know what you're all thinking, no, it was not related to incorrect quaternion math. Probably). Because of this, it was subject to error of +- 0.25 meters. That was the core of the issue, but fusing in IMU as Steve recommended was also necessary before we started to see decent results when navigating in any scenario except a straight line.line. The Adafruit BNO055 worked swimmingly for this.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
