linorobot2 problem with navigation and amcl

[Super Pömpel]

I have built a omnidirectional robot based on the linobase2 package for humble with 4 motors, teensys, imu, YDLidar scanner and a Realsense depth camera. I use a powerful x86 PC on the robot, so there is no limit in CPU performance.
I can drive around with a Joypad and create a map with slam. This works perfect. No matter how many tuns the robot makes, the map is always alligned. There is no problem with turning, moving etc. The PID parameters and encoder values have beend optimized.

But when it comes to navigation, the position of the robot drifts in the map and never will be realligned with AMCL.  I think  amcl  is not working properly. I also can not see the red  amcl  arrows for possible locations in rviz. But the amcl node is running.

I dont know where the problem is, because everything seems ok. All tf are published. The robot urdf is shown in rviz. use_sim_time is in all config files and in the commands on false. There are no errors or warnings in rviz for the topics.

But there is one problem:

When I run "ros2 launch linorobot2_description description.launch.py" on the robot it will stuck at
"Waiting for robot_description to be published on the robot_description topic"
altough "ros2 launch linorobot2_description description.launch.py" is running on the host

The command " ros2 topic echo joint_states" shows only values 0. 

[Az]

 ±10cm drift is not unsual for a quick build. Drift are commonly corrected using "docking" and position reset. Such as the ArUco, ArTag method. I use a simpler IR sensor+reflective tape and linefollower method to correct my robot position. How much drift you got? Do you have viedo recosrding of the drift. More information would help solve the issue.

Regarding "Waiting for robot_description to be published on the robot_description topic", perhaps it is waiting for "initial_pose"?

https://github.com/ros-planning/navigation2/blob/main/nav2_simple_commander/nav2_simple_commander/example_nav_to_pose.py

[Super Pömpel]

the drift is starting after moving at about +-20cm and getting worse over time. I know that a drift is not unusual but there should be some mechanism like amcl wich should correct it as much as it can. But I cannot see any attempt from the system do do that. When I do navigation, I always set the initial pose by hand in rviz. Then I get these messages:

amcl]: Setting pose (1698939176.226869): -0.014 -0.200 2.944
[component_container_isolated-1] [INFO] [1698939181.206845974] [amcl]: initialPoseReceived
[component_container_isolated-1] [WARN] [1698939181.206924652] [amcl]: Failed to transform initial pose in time (Lookup would require extrapolation into the future.  Requested time 1698939181.206888 but the latest data is at time 1698939181.179000, when looking up transform from frame [base_footprint] to frame [odom])
[component_container_isolated-1] [INFO] [1698939181.206936624] [amcl]: Setting pose (1698939181.206937): -0.176 -0.156 2.949

After setting the initial pose (with sensor data overlapping exactly the map) I can define a goal and the robot will move and reach the goal, but it would be so much better without the drift.

The  "Waiting for robot_description "message appears in the log from "ros2 launch linorobot2_bringup bringup.launch.py" followed by some messages related to the lidar and it appears as described before when "ros2 launch linorobot2_description description.launch.py" is executed, but there no other log message appears after that.

I dont know if that is even a problem. It is the only thing I can see which may be not correct.

Also, in the tf-tree, the sensor links have no timestamp for the last transform. I dont know if thats ok or not.

I will give the tag method a try, but first I have to know if there is something wrong with my setup and I think it is. 

[Super Pömpel]

I have a different question:

Is there something wrong with the teensy microcontroller software?

I configured the navigation local planner to use also the y-axis.

When the planner creates a cmd_vel_nav/linear_y movement, the robot will not absolutely not react to it. But I can see the values of the command in rqt and the direction in rviz. No matter what size the value has, the movement of the robot in y-direction is zero. For x-direction and turning everything is fine. I have not modified the source-code beside the config-parameters.

[Az]

Share pictures of your robot. I could try examine the mechanical and electronics of your build.

Lose electrical connection, dead teensy Pins is the common cause of problem. Continuity check every connection.

Redo linorobot2_hardware make sure the encoder and imu is working sufficiently. 

[Super Pömpel]

this is 100% not a electronics or hardware related problem. The robot is moving via joypad or navigation (but there without an y-only movement) very good. Everything is ok. 

The problem is only in navigation mode the robot is acting like a differential robot, not a mecanum/omni robot.

In rqt I can see that  values of cmd_vel_nav/linear_x values are sent to  cmd_vel/linear_x, but  cmd_vel_nav/linear_y values are not send to  cmd_vel/linear_x

What node is responsible for moving the nav-cmd message to cmd?

So now I think it's not the teensy, the problem must be the on the linux system. But it's not the navigation-config because, the navigation wants to move in y-axis.

[Super Pömpel]

I made a test with the message_publisher in rqt:

a manual entered value from
cmd_vel_nav/linear_x is mapped to cmd_vel/linear_x
and the robot is strafing

a manual entered value from
cmd_vel_nav/linear_y is not mapped to cmd_vel/linear_y
and the robot is not moving

somewhere the y_values are capped. I tried to modify every possible parameter realted to this in navigations.yaml but it didn't work.

in ~/.bashrc the robot is defined as mecanum. I did not made any further modifications in the parameters/code beside the navigation config. I am wondering why only I have this problem.

[Super Pömpel]

sorry, correction of the post:

I made a test with the message_publisher in rqt:

a manual entered value from
cmd_vel_nav/linear_x is mapped to cmd_vel/linear_x

and the robot is moving forward

a manual entered value at cmd_vel/linear_y
and the robot is strafing in y-axis

a manual entered value from
cmd_vel_nav/linear_y is not mapped to cmd_vel/linear_y
and the robot is not moving

somewhere the y_values are capped. I tried to modify every possible parameter realted to this in navigations.yaml but it didn't work.

in ~/.bashrc the robot is defined as mecanum. I did not made any further modifications in the parameters/code beside the navigation config. I am wondering why only I have this problem.

[Super Pömpel]

I found the error. Here is a picture of the topic map:


There is a node called velocity smoother between cmd_vel and cmd_vel_nav. 

However, this is not configured in the navigation.yaml of the linobase2 project. 

After I implemented and configured the parameters for this node, the y-movement also works. 

The navigation for my omnidirectional robot is so much better now.

I don't know where it is configured that this velocity smoother is called.
I'm currently using the humble distribution, but I also had foxy running. Same problem everywhere.

I'm surprised that I'm the only one who noticed this problem.

At least this problem has now been solved, but I'm still stuck with the drift and the actual concern of this thread.

[Thomas Chou]

Awesome. I am able to add it to drive my Mecanum robot. Big thanks.

lustigernu...@gmail.com 在 2023年11月4日 星期六上午9:50:18 [UTC-7] 的信中寫道：