Cirkit wierd behaviour

[kossumov]

Hi guys,

What I did so far:

1. create catkin_ws, clone cirkit code, execute install.sh
2. roslaunch cirkit_unit03_autorun autorun_gazebo.launch
3. give nav_goal inside rviz

After that, robot navigates to nav_goal; however, acts weirdly after that.
Here is the video:
my video

on minute 1:24 you will notice that robot weirdly starts driving backwards.

Here, on your video, I noticed that your robot drives smoothly
your video

Why does this weird behaviour happen?
Thanks

[MoriKen254]

The backward behavior is driven by stepback_and_steerturn_recovery plugin for move_base pkg.

http://wiki.ros.org/stepback_and_steerturn_recovery?distro=indigo

The plugin usually start going back when the robot find obstacle in front it. However, in your video it somewhat seems to have detected one even though it doesn't exist.

Could you put the message on your bash when the phenomenon occurs?

[RyodoTanaka]

On 1:10 of @kossumov video, the robot looks to detect itself as obstacles...
Whatever, we need a message on your bash to understand what was occurred as @MoriKen254 said.

[kossumov]

There are no errors in terminal, it looks like this all the time:

Looks like robot cannot get to nav_goal and just drives around. Here's another video:
another video

Also, here's another, longer video:
longer video

I'm using ros kinetic on ubuntu 16.04. Can you please install CIRKIT on your machine, give it nav_goal inside rviz and see if it drives correctly?

Thanks

[kossumov]

I guess the problem is with localization.

Also, I've noticed that some of lidar rays may be blocked

Am I right?

[MoriKen254]

seems you're correct. Let's try an easy solution first.

plz try to tune the LRF range parameters in https://github.com/CIR-KIT-Unit03/cirkit_unit03_simulator/blob/master/cirkit_unit03_gazebo/urdf/cirkit_unit03.gazebo.xacro#L42 & https://github.com/CIR-KIT-Unit03/cirkit_unit03_simulator/blob/master/cirkit_unit03_gazebo/urdf/cirkit_unit03.gazebo.xacro#L76

        <range>
          <min>0.10</min>
          <max>30.0</max>
          <resolution>0.01</resolution>
        </range>

I believe enlarging a value in min tag would avoid the problem.