How to use with 2 wheeled differential drive robot
Closed this issue · 12 comments
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.
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.
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)
I think this package is designed for Ubuntu 18.04 with python2, if I'm not mistaken. Which OS are you running?
I'm trying to run it on ubuntu 20.04 with ros noetic.
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.
If you would like a noetic release, please open an issue for that. We'll probably can make that happen 🙂
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.
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 😢
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:
- Create a working move_base implementation for your robot
- Switch to move_base_flex using the same planners as in (1)
- 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.
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.
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.
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 magazino/move_base_flex#224
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.