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 ...
It seems that you successfully apply the
nav2d
package on you real robot. What's the performance? Can you post a map?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.
Hey man @Sebastian Kasperski, you probably know what's going on with rviz. Please, take a look
Yeah, on my computer, the
rviz
always crashed, same with you. @gerson_n, I will try what you said. Thanks a lotHey, @gerson_n, it's
expected_update_rate
rather thanspected_update_rate
? I cannot foundspected_update_rate
in the code or yaml file.@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
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.
@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