Hello,
Is there a way to improve obstacle avoidance while waiting for the robot to achieve a goal?
I followed your tutorial on fiducial-based localization and I have an algorithm that enables object avoidance, but after sending a goal and until the robot reaches the goal, the robot might encounter obstacles and goes against them. Is there a way to guarantee obstacle avoidance using the actionlib server sending goals?
Looking forward to your reply and thanks in advance.
Catarina
I too have seen that we have not setup the obstacle detection to be good values so far. I have only done a little in this area so I will explain some pieces and you can perhaps try to set things for better detection.
I will assume that of course you have enabled the sonars in the /etc/ubiquity/robot.yaml file (I see we don’t explain this in our sonar setup page at bottom of https://learn.ubiquityrobotics.com/camera_sensors and will add this to doc improvement list that I continually work on over time.
You can see details on sonar option here: https://learn.ubiquityrobotics.com/sensors
It is best to setup RViz for sonar detection debug but if you cannot then be aware of the sonar ROS topics and monitor them to verify that the forward sonars are ‘seeing’ objects.
If you have current move_basic.cpp, which recently was updated, go into move_basic.cpp near line 700 to find this line:
double forwardObstacleThreshold = 1.5; // if distance < velocity times this we stop
What I found is it did not look far enough out so by the time the robot came upon an object that was very close and perhaps outside of the cone of detection for the forward sonar it was too late. Works for BIG objects but small ones had grief.
Next I will say that I am not convinced the two sonars that look 45 deg to right and left are considered for detection in current move_basic code well enough or perhaps at all so this must be investigated on our side. That means a single forward facing ‘cone of detection’ must see the object or we will not detect it.
Also very important for detection evaluation is to setup RViz so you can see the sonar’s as they detect things and do some static tests by placing objects in front and verify you are happy that the sonars are working.
Do you run Rviz on a laptop setup for ROS yet?
I attach the RViz screen that shows the Sonar numbers and the approximate cones of detection for each sensor. I have placed boxes at known distances and show those distances in this picture.
I think that if 2 things are done then straight ahead detection can happen better
In this way a very full coverage of out front about a half meter that spans the width of a Magni is likely.
This makes me think the next rev of the Sonar board we should consider extra holes to perhaps allow users to more easily place sonars for direct ahead full coverage.
Hope this helps. I am mostly thinking out loud here to find a solution for your needs.
Mark
Hello Mark,
First of all, thank you for your quick response.
It is best to setup RViz for sonar detection debug but if you cannot then be aware of the sonar ROS topics and monitor them to verify that the forward sonars are ‘seeing’ objects.
Yes, I have setup Rviz and I can see all the sonars’ cones. But unfortunately most of the time the cones are oscillating.
If you have current move_basic.cpp, which recently was updated, go into move_basic.cpp near line 700 to find this line:
double forwardObstacleThreshold = 1.5; // if distance < velocity times this we stop
Well, I don’t have move_basic.cpp, how can I get it? Is it by getting the repository of move_basic on my workspace? I cloned move_basic to my catkin_ws and it crash on catkin_make. I already installed the move_basic package by apt-get though.
Thank you for your availability,
Catarina
Today I took the 6-19-2019 image and pulled in move_basic to catkin_ws/src
cd ~/catkin_ws/src
git clone https://github.com/UbiquityRobotics/move_basic
cd …
catkin_make -j 1 (The -j1 limits to 1 cpu so you can make with our code running)
This made ok so I want to know how you had issues as there could be some problem I need to fix.
move_basic.cpp that is current will have now in ROS_INFO statements the text starting with ‘MoveBasic:’ This was added so it is easier to see on console where messages came from is all.
In the next few days I will try my thoughts to point sensors 1 and two much more forward but still a little off to the side. This will be a test and I will also modify my own copy of move_basic to use sensors 1,2 or 3 for detection. This will NOT be shipable but may help solve your problem AND be of value to others ‘on the side’.
I will try to keep you posted as to the progress.
Hello Mark,
The problem with the installation was indeed the -j 1 flag!
I will now edit the move_basic.cpp and maybe change the direction of the sonars.
Thank you very much!
I will report here any developments.
Catarina
Hello Mark,
I have been looking through the move_basic.cpp code and I have been wondering where in the code do you define which sonar to consider when you are avoiding obstacles.
I could not understand how do you specify only using the front sonar.
Thank you for your patience,
Catarina
Oops. In looking at this issue just now I saw the reply below never sent. Sorry.
Because you and I have been discussing other issues offline in emails I hope this has been answered in those. If not we can pick up the conversation again.
The logic is at line 903
// Stop if there is an obstacle in the distance we would hit in given time
bool obstacleDetected = obstacleDist <= velocity * forwardObstacleThreshold;
if (obstacleDetected) {
About 20 lines of code here starting at line 906 deal with waiting for the obstacle to be moved
