Faulty navigational behaviour

I have a GoPiGo (Raspberry Pi b+) that uses RPLIdar A2 for scanning. I've been trying for a long time to get mapping working properly with movement. I've searched a lot on how to fix my problems but none of the solutions seemed to work.

I'm using Ubuntu_Mate 16.04 and all the lastest stacks and updates on everything else, the repos I use are listed below.

For navigation im using https://github.com/iot-magi/gopigo3_navigation

in combination with that repository im also using https://github.com/ros-gopigo/gopigo3_node

finally, im using this repo for the RPLIdar https://github.com/Slamtec/rplidar_ros

Im getting the map and costmap up properly, and it seems to be working fine. But as I try to publish a goal to the navgoal the robot gets very confused and starts rapidly turning (i will provide a video if it's needed).

I should also point out that the map in RViz flickers a lot, which i cannot find a solution for.

I noticed something that seems off with my TFtree, GoPIGObody and LIdar has 10000 hertz average rate. Could this be causing a problem?

https://imgur.com/U8LLtqp

I have costumised some values so it works with my hardware setup.

I would greatly appreciate any help or points in the right direction. If there is anything more you want to know about my config or anything else ill answer very fast.

Asked by HaraldPed on 2019-04-24 09:40:58 UTC

Comments

I believe those Lidars run at about 30 Hz, so you may have a hardware problem or it may be misconfigured.

Also, are you running RViz on the GoPiGo, or is it running on another machine connected over the network?

Finally, can you see the Lidar points in RViz before you publish a goal?

Asked by Carl D on 2019-04-24 12:00:10 UTC

I am running RViz on another machine over the network yes, however the goal is being published via SSH, I only use RViz to get some visual on what is happening. I can see the lidar points indeed, and the map is being generated ontop of that. The lidar points are pretty accurate aswell.

Asked by HaraldPed on 2019-04-25 09:48:41 UTC

Ok. Some more questions to try to narrow down the problem.

Have you been able to drive the robot around using teleop, to confirm the hardware works?
Take a look at the path produced by the global planner and confirm it looks OK.
Take a look at the map to odom transform and confirm it is pretty stable and consistent. You can visualize the transforms in Rviz

Asked by Carl D on 2019-04-26 19:23:00 UTC

I just want to start of by thanking you for trying to help me!

The robot drives perfectly on the telop, so the hardware should not be any problem.
The global plan does seem to look okay, and the robots tries to follow it. It even spins around to go in the right direction, but when it comes near the end it starts moving back and forth. https://imgur.com/lJrVPLM If you see the image, it shows that the robots has driven a little bit on the path, but starts acting wierdly. I get warnings in the terminal which i also show in the picture.
The odom transform does seem look correct.

Asked by HaraldPed on 2019-04-27 09:22:13 UTC

The error suggest there is a problem with the local costmap. There are two costmaps in the system, one for the global planner and one for the local planner. Do both of them look correct?

Asked by Carl D on 2019-04-29 18:56:09 UTC

I dont know if it has something to do with it, but if you see on this image: https://imgur.com/4j7ciFV. The local costmap seems to be the minature map to the left of the image. They do seem to look pretty alike.

Asked by HaraldPed on 2019-04-30 12:42:31 UTC

Sorry for the delay. I've been away for a few days.Are you saying the local costmap is the grayish square? The robot is on the top right corner? That looks wrong. The robot should be centered in the local costmap. It also looks like it has no data in it. It's all the same gray color.

It looks to me like the local costmap is misconfigured. Can you post your configuration parameters? I know the params can be spread around a lot of files, so if needed, I believe you can run rosparam dump myparams.yaml to get them all.

Asked by Carl D on 2019-05-07 13:37:16 UTC

Hey! Thanks for the suggestion, I've uploaded my params to this pastebin: https://pastebin.com/ni46KS91

Asked by HaraldPed on 2019-05-07 14:38:27 UTC

I'm bit unfamiliar with the details of the rolling_window mode of costmap, so I'm not sure if this is the problem, but I believe it would make more sense for the local_costmap/global_frame parameter to be base_link instead of odom

Asked by Carl D on 2019-05-07 15:12:24 UTC