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

Navigation stack not going straight

asked 2022-04-08 11:37:18 -0500

1024son gravatar image

updated 2022-04-10 04:17:16 -0500

Hello,

I previously posted about my robot rotating in place but that has been solved as it is due to the map not being aligned.

However, the robot now turns left and right towards the set goal instead of going straight.

Have taken advice on previous post to tweak parameters like base_local_planner_params.yaml and both local and global costmap param but issue persist. Is there any possible solution to this and please let me know what information would be informative and I will update ASAP. Thank you.

Info:

  • followed: https://automaticaddison.com/how-to-s... (have went through his tutorial prior to this link as well and there are no issue)
  • SBC- Odroid C4
  • RPLiDAR a1m8
  • MCU - Arduino Uno
  • motor driver l298n
  • bno055 imu sensor
  • pololu magnetic quad encoder

Github: https://github.com/roomtempiq/Odroid_bot

Thank you very much.

edit retag flag offensive close merge delete

Comments

I have added my github repository for this project as suggested by another user.

1024son gravatar image 1024son  ( 2022-04-10 04:17:59 -0500 )edit

The robot when met with an obstacle, it is unable to change its trajectory and rotate in place. This eventually leads to the map and laser scan misaligned. Is this possibly still base_loacal_planner (for not going straight and unable to change planned path with obstacle) and amcl (laser scan) issue?

Any help even a comment on possible issue is greatly appreciated. Thank you.

1024son gravatar image 1024son  ( 2022-04-11 08:53:47 -0500 )edit

will replacing base local planner with dwa planner work?

1024son gravatar image 1024son  ( 2022-04-11 08:54:31 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2022-04-13 17:37:44 -0500

ljaniec gravatar image

updated 2022-04-14 17:55:04 -0500

However, the robot now turns left and right towards the set goal instead of going straight.

I look into your code and it looks like you have some code smells there, e.g.

// Check if we need to turn 
  if (cmdVel.angular.z != 0.0) {

    // Turn left
    if (cmdVel.angular.z > 0.0) {
      pwmLeftReq = -PWM_TURN;
      pwmRightReq = PWM_TURN;
    }
    // Turn right    
    else {
      pwmLeftReq = PWM_TURN;
      pwmRightReq = -PWM_TURN;
    }
  }
  // Go straight
  else {...}

You are checking cmdVel.angular.z != 0.0, when checking cmdVel.angular.z < SOME_MIN_DIFF would be better for uC. I am not so sure with your PWM control too - did you check it on the real robot?

// Publish tick counts to topics
leftPub.publish( &left_wheel_tick_count );
rightPub.publish( &right_wheel_tick_count );

Are these for sure synchronized? Your comment with

However, the robot now turns left and right towards the set goal instead of going straight.

seems to be connected to this.

edit flag offensive delete link more

Comments

I recalculated my ticks per meter, k_p and b constant. and it now goes left & right and straight then repeat towards the goal. Seems that it is an improvement and that the issue is contributed by the diff drive controller. I will look into what u have mentioned above and also use my new parameters and configure the base_local planner Thank you

1024son gravatar image 1024son  ( 2022-04-14 09:06:19 -0500 )edit

Left and right wheel ticks are in sync and have negligible difference when checking with rostopic echo /. If thats what u meant by synchronized. Let me know if I am mistaken and also so, what is uC? Thank you very much

1024son gravatar image 1024son  ( 2022-04-15 06:35:11 -0500 )edit

uC - microcontrollers, but I thought about hardware overall here. In reality you will never have a "pure" zero in something, it will be nearly always some 10e-7 value etc. Usually it is solved by a kind of dead zone around boundary values, e.g. abs(cmdVel.angular.z) < 0.001 should be treated as a zero. Right now I think about the frequency of your cmd_vel commands, maybe they are published less frequently than they should? How is your driver working with rapid changing of PWM values?

ljaniec gravatar image ljaniec  ( 2022-04-15 09:50:18 -0500 )edit

oh I see "u" as in micro. Will try to give an allowance for abs(cmdVel.angular.z). I used rqt_robot_steering rqt_robot_steering and publish different speed to the robot and it does react instantaneously. Will be updating later if I have better result with what I have done. Once again, thank you.

1024son gravatar image 1024son  ( 2022-04-16 06:34:55 -0500 )edit

Hello, I changed the map update and publish frequency to 60 instead of 30, changed to abs(cmdVel.angular.z) < 0.001 instead of <0.0 and it work towards the goal without rotation with a static obstacle!

So I tried to find out if it's the map parameter or the angular allowance that made this improvement by:

  1. changing the angular back to '<0.0' with updated map param
  2. changing map param to 30hz with updated abs(cmdVel.angular.z) < 0.001

Changing abs(cmdVel.angular.z) < 0.001 back to zero shows the rotation problem. But updating it back to abs(cmdVel.angular.z) < 0.001 does not replicate the first time I did it. Why is this happening? Update: I further tried with a smaller value of 0.0001 and 0.00001. It remains the same. I guess i made a mistake? I ...(more)

1024son gravatar image 1024son  ( 2022-04-16 09:03:11 -0500 )edit
1

I am not sure what are you asking here, to be honest, with replicating things etc. With values - you know for sure from school inequalities with a module, e.g. |x| < 0.1 or |x| < 0.01 - the first one has a bigger range of solutions: (-0.1; 0.1), second one smaller: (-0.01;0.01). If you increase RHS of this inequality you will get bigger "dead zone" around zero - this way your code is more robust to small differences, e.g. controller will wait for bigger differences to change it's control. Smaller RHS - more sensitive control.

ljaniec gravatar image ljaniec  ( 2022-04-16 18:31:04 -0500 )edit

Yes I understand what you mentioned. I overlook things as I was constantly trying and my brain kind of died. What I meant by replicating is that I am unable to get the perfect run even after changing the values back to the perfect run values. Will update later. Thank you

1024son gravatar image 1024son  ( 2022-04-17 03:54:12 -0500 )edit

Hello, sorry for posting late as I was writing and finishing my report for this project as it is due yesterday. I am now getting a much reliable result after changing to

// Turn left
if (cmdVel.angular.z > 0.4) {
  pwmLeftReq = -PWM_TURN;
  pwmRightReq = PWM_TURN;
}
// Turn right    
else if (cmdVel.angular.z < -0.4) {
  pwmLeftReq = PWM_TURN;
  pwmRightReq = -PWM_TURN;
}

Checked the angular value with rostopic echo /cmd_vel and it is 0.5 for left and -0.5 for right. And also tried it with dwa_local_planner instead. Thank you.

1024son gravatar image 1024son  ( 2022-04-19 13:50:08 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2022-04-08 11:37:18 -0500

Seen: 570 times

Last updated: Apr 14 '22