2017-01-03 15:37:03 -0500 received badge ● Famous Question (source) 2017-01-03 15:36:20 -0500 received badge ● Notable Question (source) 2016-12-30 22:18:19 -0500 commented question Tricycle Model Fixed! (mostly) Ha, thank you for the heads up! Fingers crossed someone there can help :) 2016-12-30 22:17:09 -0500 received badge ● Popular Question (source) 2016-12-30 12:24:13 -0500 asked a question Tricycle Model Fixed! (mostly) I've rewritten the tricycle plugin so that it now produces good navigation using rqt commands in Gazebo, with good correspondence to maps produced in rviz using rtabmap. You can download my code to experiment with here :) My inspiration came from the Instantaneous Centre of Rotation discussion here. Input is greatly appreciated! Let me know if there are other files you need in order to play around with it. ONGOING ISSUES: 1) I'm concerned that my sign conventions for x and y seem to be reversed (compared to what I imagined them to be) in the code (see line 357 onward). Motion looks good in simulations, but I worry that this is producing the troubles I've experienced reaching 2D nav goals in rviz (aborts goals, tries to "back in" to them). It could be a deeper problem with the teb_local_planner not really being designed for Ackerman robots, but I definitely don't see it helping if the robot wants to "back in" to all sent goals. 2) Possibly related is the fact the velocities in odom seem to be given in the global frame. With the differential drive plugin, you only ever see linear x velocity being non-zero (linear y velocity = 0 always). Could this be because the odom updates (for the steering wheel location/orientation) are being defined by reference to the "special point" between the rear wheels (see line 401)? Also possibly related is an apparent (systematic) mismatch between the twist message in odom and the cmd_vel values? These values match when using the differential drive plugin, but does the difference in kinematics for an Ackerman robot make a mismatch here totally normal? 3) Another concern is drift. Errors accumulate when switching between hard clockwise and counterclockwise turns. There may be an issue with how I've handled setting the steering angle to avoid jittering around angle = 0 (see line 288). Alternatively, it might be a problem with the friction in my model? 2016-12-01 14:01:21 -0500 received badge ● Notable Question (source) 2016-12-01 10:37:49 -0500 received badge ● Editor (source) 2016-12-01 10:37:06 -0500 received badge ● Popular Question (source) 2016-11-30 12:20:21 -0500 received badge ● Student (source) 2016-11-30 12:17:59 -0500 asked a question Tricycle Model (rqt fix!) Odometry Issue New to ROS, but I am trying to get the tricycle model plugin to accurately respond to rqt commands and update its position in rviz. I was able to get good response to rqt commands in Gazebo by: Amending the GazeboTricycleDrive::motorController function to account for forward and reverse motion (so, when moving backwards, it flips acceleration and deceleration), and Changing from '+/- steering_speed_' based angle corrections to something like below: if ( steering_speed_ > 0 ) { double diff_angle = current_angle - target_angle; if ( fabs ( diff_angle ) < steering_angle_tolerance_ ) { applied_angle = target_angle; // applied_steering_speed = 0; } else if ( diff_angle < target_angle ) { applied_angle = current_angle + steering_speed_ * dt; // applied_steering_speed = steering_speed_; } else { applied_angle = current_angle - steering_speed_ * dt; // applied_steering_speed = -steering_speed_; }  } Despite this fix helping to get the tricycle responding well with rqt commands, it produces strange artefacts in rviz --- when rotating, the walls all appear to rotate with the tricycle. It would appear that the tricycle doesn't know that it's rotating, and continues to update its map as though it were always facing forward (see screenshots). The GazeboTricycleDrive::UpdateOdometryEncoder() function appears to be using the exact same physics as the differential drive plugin. I have a suspicion that this is where the error is creeping in: the rear wheels are rotating at the same speeds and it will therefore never register any rotation from the encoders. I tried to gut the existing UpdateOdometryEncoder() code and replace the pose_encoder_.x, pose_encoder_.y, pose_encoder_.theta updates with dx, dy, and dtheta values deriving from these sources: Source 1 Source 2 My code looks something like: // Calculate odom_ based on steering wheel angle/velocity double angle_steer = joint_steering_->GetAngle ( 0 ).Radian(); double current_speed = joint_wheel_actuated_->GetVelocity ( 0 ); // From http://iiith.vlab.co.in/?sub=21&brch=72&sim=511&cnt=1 /* Steering angle = alpha; separation_steering_wheel_ = B; separation_encoder_wheel_ = 2*d; steering wheel speed = V_F Rate of rotation about ICC : omega = V_F * sin ( alpha ) / B Turning radius : R = B / tan ( alpha ) Angular velocity : V = omega * R = V_F * cos ( alpha ) Left wheel speed : V_L = omega * ( R + d ) = V + d * V_F * sin ( alpha ) / B Right wheel speed : V_R = omega * ( R - d ) = V - d * V_F * sin ( alpha ) / B */ // Method 1 - use these vl, vr values in the original odom calculations double omega = current_speed * sin ( angle_steer ) / separation_steering_wheel_; double ang_vel = current_speed * cos ( angle_steer ); double vl = ang_vel + d * current_speed * sin ( angle_steer ) / separation_steering_wheel_; double vr = ang_vel + d * current_speed * sin ( angle_steer ) / separation_steering_wheel_; common::Time current_time = parent->GetWorld()->GetSimTime(); double seconds_since_last_update = ( current_time - last_odom_update_ ).Double(); last_odom_update_ = current_time; // Method 2 - simply assume no slip on steering wheel, and calculate dx, dy, dtheta from its motion double dx = current_speed * cos ( angle_steer ) * cos ( pose_encoder_.theta ) * seconds_since_last_update; double dy = current_speed * cos ( angle_steer ) * sin ( pose_encoder_.theta ) * seconds_since_last_update; double dtheta = current_speed / separation_steering_wheel_ * sin ( angle_steer ) * seconds_since_last_update;  But neither method fixes the problem of the moving map, and it also creates some wonky looking movement in rviz. IF my logic is fine, should I be grabbing my angles from elsewhere? I get the sense using pose_encoder_.theta isn't strictly kosher. Any help is appreciated. Please let me know if there's any other information you need. EDIT: To clarify, the ... 2016-11-25 12:03:06 -0500 received badge ● Enthusiast 2016-11-16 16:23:37 -0500 commented answer libpointmatcher not found tinoki or libing64 --- were you required to change any of the directory/cmake file names? I've tried following these instructions and have had no luck getting either catkin_make or catkin_make_isolate to work.