delayed data transfer rate using nav2d

Question

Hi everyone,

I've had some troubles when I call StartMapping and StartExploration through rosservice calls for this package. According to my previous post previo, there is something wrong inside controlador_de_motor.

When I use teleop_twist_keyboard node to drive my robot, I haven't had troubles and it moves as it should. But when I order StartMapping, the robot after drives forward and turns 360° zigzagging. I've attached a short video in order you can see how it is video (for faster and slower velocities is the same)

As I'm not familiarized with arduino, I'd like you could explain me how the data transfer rate works in this case, what should I correct in there or for operator node. To me seems there is a delay in Operator node to take velocity and direction commands from cmd_vel topic.

On the other hand, after a while in the exploration process or when I move the camera, rviz stucks and stop working. There must be a way to refresh rviz or see what could be causing that, so I hope you can tell me what's going on in rviz.

EDIT 1:

I solved the zigzag by decreasing Kp and increasing max_velocity inside operator.yaml. Unfortunately rviz keeps going down after a while and the map isn't accurate after calling StartMapping. Because of that the robot wander and eventually crashes. So, according to the post which parameters should I change for updating in a good way the map?

I thought static map should be true since I noticed the map is always changing, but keeps changing everytime the robot cross the same place. On the other hand, rviz keeps going down, sometimes by its own and also when I move the grid map.

I've attached a picture of rviz below, and here yaml git my nav2d configuration; costmap, mapper, navigator, operator and ros.yaml.

EDIT 2

I solved part of the navigation task by using almost all default parameters. I updated the parameters I'm using on github, but still having the same problem from the beginning for rviz. It stucks sometimes and other goes down here pictures there are more pictures.

Now I think the map updates as it should. But because of the rviz problem I have, it doesn't update in a good way. I hope you can clarify me about what could origin this. I'm sure that grid_resolution, some threshold or the other grid parameters are the responsibles of this issue.

EDIT 3

EDIT 4

I managed to improve the map accuracy and now seems that doesn't overflow as before. Below I uploaded a picture of the map I got. .

EDIT5

I had forgotten to say that it's SOLVED. A few days ago I managed to get the same kind of map for EDIT 4, but now it's stable (I had other problem for odometry and a loose bracket in one wheel).

Now I'm facing how to avoid stairs. By the moment there are two possible solutions: stairsdetection and cliff_detector. Both of them uses depth image and RANSAC algorithm, but I'm not sure how it would be perceived by costmap layer. If it's an obstacle maybe just avoid stairs, but if that is not the case, maybe a map bound (which would be great).

Thanks

---

Originally posted by gerson_n on ROS Answers with karma: 43 on 2017-10-14

Post score: 0

---

Original comments

Comment by l_a_den on 2017-10-16:
It seems that you successfully apply the nav2d package on you real robot. What's the performance? Can you post a map?

Comment by gerson_n on 2017-10-16:
I'm still having the same torubles. The map isn't accurate and seems change everytime the robot sees the same things inside it. Also I noticed the robot position inside the map takes like half of second to get its position meanwhile it's moving.

Comment by gerson_n on 2017-10-16:
Hey man @Sebastian Kasperski, you probably know what's going on with rviz. Please, take a look

Comment by l_a_den on 2017-10-18:
Yeah, on my computer, the rviz always crashed, same with you. @gerson_n, I will try what you said. Thanks a lot

Comment by l_a_den on 2017-10-18:
Hey, @gerson_n, it's expected_update_rate rather than spected_update_rate? I cannot found spected_update_rate in the code or yaml file.

Comment by gerson_n on 2017-10-18:
@l_a_den Hey i_a_den, it's expected_update_rate what was causing the rviz crashing randomly, try setting it to 0.0. BTW now I've updated the .yaml files. By the moment the map seems work, but because of my room at some point it takes some seconds identify a wall and I have to stop it

Comment by gerson_n on 2017-10-18:
To me seems to be an update mapping problem, so I'll keep changing some parameters related to get a more accurate map. That's the only way the robot could mapping it environment in a good way, even if there are sudden obstacles like persons.

Comment by gerson_n on 2017-10-18:
@l_a_den You know what? the rviz crashing also depends of update/publish frecuency, map_update_rate and transform_publish_period mostly haha. So, we need to find a way to coordinate all tf and rates to get a decent map and don't crash with borders

Comment by l_a_den on 2017-10-18:
@gerson_n The RVIZ also crashed, Even I change the expected_update_rate to 0.0. I found that if I donot do any operator on rviz(like zoom in/out, move, etc), the rviz will not crash with a high probability.

Comment by gerson_n on 2017-10-19:
HI @l_a_den, I've updated the yaml config I have. Now rviz doesn't crash. I'm sure transform_publish_period, MinimumTravelDistance, expected_update_rate and transform_tolerance are the parameters which causes rviz crashing. I've also attached a picture of the map I got

Comment by l_a_den on 2017-10-20:
Hi @gerson_n, your map looks great, but I have some question:

1. Is there a real robot in a real room? What sensors do you using, seems like a Kinect?
2. Form what I know that the room seems should be a closed-environment, otherwise the robot will not travel so fa as you show on picture?

Comment by gerson_n on 2017-10-20:
@l_a_den yes, I'm working with a real robot in a real room. As fake scanner laser I'm using kinect xbox 360 model 1414 V1. In relation to the space, it should mapping everywhere it can cross, until there is no way to cross a tight space.

Comment by gerson_n on 2017-10-20:
@l_a_den if something block its planning road, it changes the course for reaching to another unexplored place. In my case, if it'd started on the square above and I'd block its unique way to explore the rectangular region below, it would have finished its exploration.

Comment by l_a_den on 2017-10-20:
@gerson_n I see, it's seems great with the map. Cheers! And what is the size of the room?

Comment by gerson_n on 2017-10-20:
You're welcome. It's like 7x7m^2 and the rectangular one 15x7 I guess

Answer 1

To me seems there is a delay in Operator node to take velocity and direction commands from cmd_vel topic.

There should be no delay in the Operator's actions. It should output cmd_vel at a fixed rate (iirc it's100 HZ). You should probably check the load on your robot's CPU, maybe some nodes cannot keep up and cause the whole system to act weird.

---

Originally posted by Sebastian Kasperski with karma: 1658 on 2017-10-18

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by gerson_n on 2017-10-18:
Hey @Sebastian Kasperski thanks for your reply. Since I set the LOOPTIME to 200 ms inside 'controlador_de_motor', everything seems work and for the real robot features too. So, without changing looptime for cmd_vel delivery commands for velocity and direction...

Comment by gerson_n on 2017-10-18:
I'd like you could suggest me what should I change for map updating, because that's the only thing I think is missing to improve its accuracy and don't stuck sometimes.

Comment by Sebastian Kasperski on 2017-10-19:
What is the issue with the map? When there are people walking along while you map, they are likely to appear in the map. It will take a few more readings before they disappear from the map again. Is that what you meant with 'accuracy'?

Comment by gerson_n on 2017-10-19:
Yes, it identifies people inside it as a point and avoid them. Once it reaches at the same point and doesn't see people, it clear the space. I've updated the page and added a picture of what I got. Btw, on my tf tree, kinect publishes at 10000 [Hz], even if I set it to 10 Hz inside my transforms.

Comment by gerson_n on 2017-10-19:
In the tf tree here, if you notice the most recent transform is 0.000 (1508417855.133 sec old). That's because of expected_update_rate, right?

Comment by gerson_n on 2017-10-19:
Hey @Sebastian Kasperski, I've updated the post and now the map is getting better. On the other hand, sometimes crashes for unexplored regions, which are close edges, like the last picture I uploaded. Could you tell me how can I fix that behavior for edges? (parameters inside yaml files).

Comment by gerson_n on 2017-10-19:
I'd like to know if I can set a kind of reverse mode if suddenly sees an obstacle knowing that at it side there is a border

Comment by Sebastian Kasperski on 2017-10-20:
What node publishes these transforms? Aren't they static?

If the robot crashes, this has nothing to do with the map, but with the Operator. You may need to look at the Operator's costmap. And always check rqt_console for warnings and errors.

Comment by gerson_n on 2017-10-20:
Thanks Sebastian. I'll take a look at the Operator's costmap and rqt_console for possible errors. For tutorial3 I'm using the same nodes for autonomouse exploration: Operator, Navigator, Mapper and Remote. The static ones are tf for kinect to base_link, camera_link and between base_link and odom.

Comment by gerson_n on 2017-10-20:
I checked the Operator's costmap and certainly is slow to update the things it sees. On the other hand, on rqt_console it shows only one warning "laser scan contains NaN values" That must be because of tf_tree for kinect sensor as I mentioned above. I've read some other forums which say that...

Comment by gerson_n on 2017-10-20:
I can fix that by using sim_time true, unfortunately that isn't my case and if I do so, can't stablish communication with input devices like kinect and arduino.

Comment by gerson_n on 2017-10-20:
Hey @Sebastian Kasperski, I forgot to say that the robot only crashes sometimes when it tries to reach to close edges (90° and lower, like the picture). In that case, for operator the safety and distance weights seems worse that behavior, and the safety decay for the map either