How to use with 2 wheeled differential drive robot

[benjaminnicolas]

Hi,

I'm trying to use your path planner with my 2 wheeled differential robot. I adapted test_full_coverage_path_planner.launch to launch amcl instead of a robot simulation(I'm not sure whether this is correct or not). It displays my map with a correct path and the robot on it but:

• there is a huuuuuge yellow semi-transparent circle on top of it
• it give me 'zip' object has no attribute 'pop' error in path_interpolator.py at line 490
• the robot doesn't move

I'm trying to run it on ubuntu 20.04 with ros noetic.

Could you, please, help me sort those problems out ? Thanks.

[benjaminnicolas]

About the python error, I managed to fix it. But now it gives me this: Exception in thread Thread-10: Traceback (most recent call last): File "/opt/ros/noetic/lib/python3/dist-packages/nav_msgs/msg/_OccupancyGrid.py", line 139, in serialize buff.write(struct.pack(pattern, *self.data)) struct.error: required argument is not an integer

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/opt/ros/noetic/lib/python3/dist-packages/rospy/topics.py", line 882, in publish self.impl.publish(data) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/topics.py", line 1066, in publish serialize_message(b, self.seq, message) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/msg.py", line 152, in serialize_message msg.serialize(b) File "/opt/ros/noetic/lib/python3/dist-packages/nav_msgs/msg/_OccupancyGrid.py", line 140, in serialize except struct.error as se: self._check_types(struct.error("%s: '%s' when writing '%s'" % (type(se), str(se), str(locals().get('_x', self))))) File "/opt/ros/noetic/lib/python3/dist-packages/genpy/message.py", line 383, in _check_types check_type(n, t, getattr(self, n)) File "/opt/ros/noetic/lib/python3/dist-packages/genpy/message.py", line 302, in check_type raise SerializationError('field %s must be a list or tuple type' % field_name) genpy.message.SerializationError: field data must be a list or tuple type

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner self.run() File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 234, in run self._callback(TimerEvent(last_expected, last_real, current_expected, current_real, last_duration)) File "/home/benjamin/navros_ws/src/full_coverage_path_planner/nodes/coverage_progress", line 136, in _update_callback self.grid_pub.publish(self.grid) File "/opt/ros/noetic/lib/python3/dist-packages/rospy/topics.py", line 886, in publish raise ROSSerializationException(str(e)) rospy.exceptions.ROSSerializationException: field data must be a list or tuple type

The robot moves a bit but I still have the huge yellow circle. And as the robot moves, it looks like it draws more and more of those circles because I can't see anything after a few movements.

[benjaminnicolas]

Ok I managed to fix it by changing the initialization of the grid in _initalize_map()

#grid.data = self.DIRTY * ones(grid.info.width * grid.info.height)
grid.data = [[self.DIRTY for i in range(grid.info.width)] for j in range(grid.info.height)]

But now I have another error ! How is that possible? Not the same python version ? I'm working with python 3.8.2

Now it gives me this: Exception in thread Thread-10: Traceback (most recent call last): File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner self.run() File "/opt/ros/noetic/lib/python3/dist-packages/rospy/timer.py", line 234, in run self._callback(TimerEvent(last_expected, last_real, current_expected, current_real, last_duration)) File "/home/benjamin/navros_ws/src/full_coverage_path_planner/nodes/coverage_progress", line 129, in _update_callback self.grid.data[array_index] = max(0, self.grid.data[array_index] - self.coverage_effectivity) TypeError: unsupported operand type(s) for -: 'list' and 'int'

EDIT: My fix was not correct because I was creating a 2D list. I changed to grid.data = [self.DIRTY] * (grid.info.width * grid.info.height)

[Rayman]

I think this package is designed for Ubuntu 18.04 with python2, if I'm not mistaken. Which OS are you running?

[benjaminnicolas]

I'm trying to run it on ubuntu 20.04 with ros noetic.

[benjaminnicolas]

Quick update: As the problems listed above are resolved, I'm now trying to make it work well with my robot. I have odometry published on /odom, a motor controller with a driver listening to /cmd_vel, a lidar publishing on /scan and a map. As I said in my first comment, I added amcl to the launch file, but the robot never finds its real position on the map and it moves in a strange way, and never follows the path.

[Timple]

If you would like a noetic release, please open an issue for that. We'll probably can make that happen :slightly_smiling_face:

Your last problem description is a bit vague. If the robot never finds its real position it's an AMCL problem, not this package. Once the localization is solved, we can look into "moves in a strange way" if that is still an issue after that.

[benjaminnicolas]

Hi, thanks for your answer.

About the noetic release, I will probably open an issue for that, but for the moment it seems to work with only a few changes.

About the localization, you are right it might be an AMCL problem, but it's strange because I already used it successfully for simple point to point navigation.

I feel like there are some conflicts between a few things (2 nodes publishing on /cmd_vel ??). The output of rqt_graph is incredibly complex

I have no idea of who is responsible of calculating values for the geometry_msgs/Twist messages published over the /cmd_vel topic. Is tracking_PID necessary ? Is move_base launched by move_base_flex ?

And also, what are those topics ?? /clara/collision_cloud /clara/jupiter_abs_odom /clara/move_base/TebLocalPlannerROS/global_plan /clara/move_base/TebLocalPlannerROS/teb_poses /clara/scan /clara/set_pose

I am conscious that I'm flooding you with questions and I'm sorry about that, but to be honest I feel very lost while trying to use your package :cry:

[Timple]

Is tracking_PID necessary?

No any local planner can be used to follow the path

Is move_base launched by move_base_flex ?

Not really, move_base_flex launches a small relay node that identifies as move_base and offers the same interfaces for convenience

And also, what are those topics ??

The clara namespace was a leftover of our hardware tests I'm afraid, I've removed them.

However the test map is used for testing the package. Not for expanding as launch files.

---

My recommendation would be to follow the next steps:

1. Create a working move_base implementation for your robot
2. Switch to move_base_flex using the same planners as in (1)
3. Switch to the full_coverage_path_planner as global_planner plugin.

For any help on the first two steps I'd suggest you look for answers on answers.ros.org.

[benjaminnicolas]

Thank you for taking some time to answer me.

I followed your recommendation, I successfully created a working move_base implementation Then when I switched to move_base_flex it says this:

[ WARN] [1598278990.065777035]: No plugins loaded at all!
[ WARN] [1598278996.242841994]: No plugin loaded with the given name "navfn/NavfnROS"!
[FATAL] [1598278996.243932679]: The states RECALLED and REJECTED are not implemented in the SimpleActionServer!

I already had those before but didn't know where they were coming from. I tried apt install ros-noetic-navfn but it's already there.

[benjaminnicolas]

I took some time to understand how it works and realized that the problem comes from tracking_pid after changes I made in path_interpolator.py to try to make it work with ros noetic.

Sorry for the trouble.

[amyjohansson1994]

hi @benjaminnicolas I am also getting the error The states RECALLED and REJECTED are not implemented in the SimpleActionServer! . Can you please share how you solved this, or where I should look into for this. Thank you.

EDIT: the source of error was in the move_base_legacy_relay.py from move_base_flex package. This bug has been solved at https://github.com/magazino/move_base_flex/issues/224

[ElClopitan]

In case anyone has this issue in the future, I fixed the overlay issue by first giving an initial pose position such that the map to odom transform is around (5,5), second setting the coverage_area_offset in test_full_coverage_path_planner.launch to and setting coverage_area_size_x and coverage_area_size_y to 15 instead of 10, and finally change the grid.yaml such that the origin: [0, 0, 0.0]. Something seems to have not been transforming the path correctly so that may need to be fixed but this fixed everything for me.