# delayed data transfer rate using nav2d

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 ...

edit retag close merge delete

It seems that you successfully apply the nav2d package on you real robot. What's the performance? Can you post a map?

( 2017-10-16 03:53:15 -0500 )edit

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.

( 2017-10-16 09:22:52 -0500 )edit

Hey man @Sebastian Kasperski, you probably know what's going on with rviz. Please, take a look

( 2017-10-16 13:19:18 -0500 )edit

Yeah, on my computer, the rviz always crashed, same with you. @gerson_n, I will try what you said. Thanks a lot

( 2017-10-18 03:36:06 -0500 )edit

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.

( 2017-10-18 03:40:29 -0500 )edit

@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

( 2017-10-18 12:11:39 -0500 )edit

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.

( 2017-10-18 12:15:00 -0500 )edit

@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

( 2017-10-18 14:50:19 -0500 )edit

Sort by » oldest newest most voted

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.

more

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...

( 2017-10-18 12:31:52 -0500 )edit

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.

( 2017-10-18 12:34:57 -0500 )edit

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'?

( 2017-10-19 03:08:27 -0500 )edit

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.

( 2017-10-19 09:18:59 -0500 )edit

In the tf treehere, if you notice the most recent transform is 0.000 (1508417855.133 sec old). That's because of expected_update_rate, right?

( 2017-10-19 09:36:49 -0500 )edit

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).

( 2017-10-19 12:27:43 -0500 )edit

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

( 2017-10-19 12:47:10 -0500 )edit

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.

( 2017-10-20 01:39:27 -0500 )edit