ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

delayed data transfer rate using nav2d

asked 2017-10-14 09:51:11 -0500

gerson_n gravatar image

updated 2017-11-03 11:29:08 -0500

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

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

edit retag flag offensive close merge delete

Comments

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

l_a_den gravatar image l_a_den  ( 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.

gerson_n gravatar image gerson_n  ( 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

gerson_n gravatar image gerson_n  ( 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

l_a_den gravatar image l_a_den  ( 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.

l_a_den gravatar image l_a_den  ( 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

gerson_n gravatar image gerson_n  ( 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.

gerson_n gravatar image gerson_n  ( 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

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

1 Answer

Sort by » oldest newest most voted
2

answered 2017-10-18 10:03:02 -0500

Sebastian Kasperski gravatar image

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.

edit flag offensive delete link more

Comments

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

gerson_n gravatar image gerson_n  ( 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.

gerson_n gravatar image gerson_n  ( 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'?

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 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.

gerson_n gravatar image gerson_n  ( 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?

gerson_n gravatar image gerson_n  ( 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).

gerson_n gravatar image gerson_n  ( 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

gerson_n gravatar image gerson_n  ( 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.

Sebastian Kasperski gravatar image Sebastian Kasperski  ( 2017-10-20 01:39:27 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2017-10-14 09:51:11 -0500

Seen: 554 times

Last updated: Nov 03 '17