Hello again, I’m having a lot of issues with the Summit-XL course. Firstly, visually in RVIZ, the robot’s wheels often don’t appear correctly in relation to the rest of the body or remain at the origin where they initially appeared. Secondly, the map doesn’t seem to be generated accurately in mapping (all steps followed as per the course and repeated three times with similar results). One part of the map is scanned correctly, but then it loses reference or something similar, merging parts of the map. Finally, I encountered another problem in the section on exterior GPS navigation. When attempting to install the GPS visualization package in RVIZ, rviz_satellite, it fails to compile the repository obtained from GitHub (git clone https://github.com/gareth-cross/rviz_satellite.git) and then compiling it with catkin_make. The latest error is as follows:
plaintextCopy code
CMake Error at rviz_satellite/CMakeLists.txt:26 (find_package):
By not providing "FindGeographicLib.cmake" in CMAKE_MODULE_PATH this
project has asked CMake to find a package configuration file provided by
"GeographicLib", but CMake did not find one.
Could not find a package configuration file provided by "GeographicLib"
with any of the following names:
GeographicLibConfig.cmake
geographiclib-config.cmake
Add the installation prefix of "GeographicLib" to CMAKE_PREFIX_PATH or set
"GeographicLib_DIR" to a directory containing one of the above files. If
"GeographicLib" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
See also "/home/user/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/user/catkin_ws/build/CMakeFiles/CMakeError.log".
Makefile:332: recipe for target 'cmake_check_build_system' failed
make: *** [cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed
Thanks for the report.
We have assessed the issue and it seems that that system is deprecated and note working anymore. We will need to update the course or remake it to make all those features work again.
As for the mping issue, specially outdoors, we detected that issue that mapping doesn’t work that well when we are in open environments that are pretty poor in features. In a more rich environment with more organic details it will work better if your odometry system doesn’t skid a lot in dirt.
Sorry fo the inconvenience, we will see into fixing the course or updating it as soon as we can
I understand that sometimes, you do not see the wheels properly shown in Rviz, even if they properly show on the simulation. Something like this:
The reason that it happens sometimes and sometimes not, is that sometimes the controller doesn’t load when the simulation is launched. This is a random problem that happens specially the first time a simulation is launched. We are working to solve this, even if it is difficult because it is a problem ROS tries to launch the controllers when Gazebo is not yet loaded). We are working on solving this as soon as possible.
In the mean time, the provisional solution I can give you for that is you restart the simulation (using the first icon from the left in the simulation window that says Restart the simulation). Everything should show properly after restart.
Yes I know this is not how it should be, but it is a workaround meanwhile we provide a better solution.
About the map not generating properly, I think I know what is your problem: the value of the parameter maxUrange is very low (5.0 meters). This means that any laser data further away than 5 meters from the robot will not be taken into account for the building of the map. That is discarding an immense amount of data from the laser, so the mapping algorithm can get lost when not enough data available.
Change that parameter in the gmapping.launch file by this value to take advantage of the full range of the laser (10 meters) and try again:
The instructions to clone the repo for the rviz_satellite plugin are correct. However, the repo has changed since we created the course and then the compilation fails.
In order to solve this do the following:
I. remove the build and devel of your catkin_ws
II. remove the cloned repo of the plugin
III. clone the repo again with the following command (we will force the version that compiles properly):
Ok, thank you very much. Here are the results obtained:
Problem 1 with wheel positioning: It seems that restarting the solution solves the issue. It can be said that it’s resolved even though it hasn’t been tested further.
Problem 2 with mapping: I’ve made two attempts with the modification of that parameter. In the first attempt, I increased the robot’s linear velocity to 1.3 to accelerate mapping, but encountered the same problem of bad scanning. In the second attempt, reducing the velocity to the normal value resulted in a proper map without scanning issues. It’s resolved, but I’m not sure if it’s due to the robot’s velocity during scanning or the parameter mentioned, because I believe I did the same before your response and after several attempts, managed to map the area correctly without changing the parameter.
Problem 3: After the mentioned steps, it compiles correctly and reloading RVIZ shows the rviz_satellite section. Resolved.
ADDITIONAL DOUBTS:
ABOUT ADDING THE TOKEN_ACCESS: When passing the TOKEN_ACCESS to the RVIZ URI, am I supposed to manually pass it in RVIZ or is there a way to pass it automatically through script configuration?
INITIAL POINT IN NAVIGATION: If navigation starts, whether indoor or outdoor via GPS, from a point different from where scanning started, the robot fails to reach the actual point on the map. I understand that this is not yet addressed for resolution, or is there a way through the self-localization with EKF to obtain the correct position by moving it??
PACKAGES AND TOPICS THAT DIFFER IN THE REAL ROBOT FROM THE COURSE: — On one hand, the topics where GPS, IMU, and odometry data are obtained from the Summit XL robot are different from the course. In our robot, GPS is obtained with /robot/gps/fix, IMU with /robot/imu/data, and odometry with /robot/robotnik_base_control/odom. — Similarly, velocity is passed via /robot/move_base/cmd_vel and position — On the other hand, in the navsat_transform_node example, the course topics are used without “/robot” so probably that’s why nothing is shown in the output topic /odometry/gps, similarly, nothing is shown when echoing the topics of gps/filtered (shouldn’t this influence GPS navigation or not?)
OPERATION OF OUTDOOR NAVIGATION: I don’t understand if the files are correct due to the aforementioned points. I understand that the navsat node, the ekf_localization node, the map_server node, and finally the move_base_map node need to be launched for outdoor navigation. But how do they interact with each other, does it really work correctly as in the course, or is there a flaw in some point of the files?
ADDING WAYPOINTS FROM POINTS OBTAINED BY GPS FOR EXTERIOR NAVIGATION. How can this be done? I understand that there is a package for indoor navigation, but I’m not sure if it would work for outdoor navigation.
DOUBT ABOUT RTK GPS OPTION: Is there a way for GPS data to be corrected using RTK, because I understand that the robot’s GPS allows it. Any guide on this?
About the problem of speed while creating a map: yes that is definitely a problem! You cannot accelerate mapping by accelerating speed of the robot because then, there will be less points per each position. Also, the odometry will have more errors (because the odometry algorithm is computed based on a small position change between steps). Then if you CPU is slow (like is in this case) and the laser frequency is not very fast (20Hz or more) then your map will be prone to errors.
Other things that affect map building: colliding agains obstacles (this produces a huge amount of odometry error), large corridors where the robot cannot detect the end, large loops, etc…
You can add the toke in the .rviz config file itself. you will see the structure if you open the config file provided in the link. Follow the instructions of the course to identify where to put the token
I don’t understand this question. Please include screenshots to clarify
It may happen that the topic names have changed in the real robot. We cannot keep a 1-to-1 with all the changes that Robotnik does. This is just a matter of identifying the topic names and putting the correct ones in your code of the robot. This is very common in ROS. Just modify your configuration files.
The course provides you with a working example. You just need to modify to your own robot. That usually means, checking the files you created and substituting the topic (or frames) names by the ones your robot has.
I don’t know how to integrate RTK. What I would do is to se the robot_localization package, that you are using to mix the GPS data, and mix there the RTK information. I don’t know if it is the best way of doing it, it is what I can think right now. Check our course about robot_localization to learn more about it: Fuse sensor data to improve localization (Fuse Sensor Data to Improve Localization course - hands-on | The Construct)
When answering your questions, it is not very clear for me when are you talking about the real robot or the simulated robot of the course. Please clarify in your questions when you are talking about the course simulation or the real robot
Hi again,
About the previous question that i didnt explain well: about indoor navigation: what happens if the initial point from which the robot departs differs from the origin of the scanned map. that is, in navigation with a static map, if the robot begins navigating at point1 and the origin of the static map is different (point2), when the map is loaded, the robot appears in a different place on the map than in reality. is this a problem of mapping or is it implicit in navigation, which must start navigating from the same initial point?
about outdoor navigation. we already have located the topics that obtain the gps data (/robot/gps/fix), imu (/robot/imu/data), and odometry (/robot/robotnik_base_control/odom) but the internal navsat_transform_node (seen by rosnode info navsat_transform_node) node subscribes to the topics /gps/fix and /imu/data, which do not exist on the robot and publishes to /odometry/gps. therefore, it may be that the error of not getting data from said node, and outdoor navigation does not work for that reason.
Regarding the rest of the responses, thank you very much for your help, and I will watch the video to find the possible fault.
Hi Cetemet,
every time you start the navigation system, you need to provide to it the initial position of the robot, that is, where in the map is the robot starting today. This is unavoidable. The robot cannot figure out by itself.
How do you do that? There are several methods:
Provide it using rviz and the 2D estimate pose button
include the initial location in the amcl config file (if you know that the robot will start every day from the same location)
Use global localization
By doing that question, I can see that you lack basic knowledge of the navigation system of ROS. You need to take the ROS Navigation course where all those doubts will be answered
The Summit XL course is not intended a full course on ROS. It is a course about how to configure the ROS navigation system (and other things) with the Summit XL. Even if we teach many things there, you should have the basics of mapping and so on. Please take the following courses to get the most of the knowledge:
For the names of the topics being different, no problem, you only need to do a remap of the names of the topics. Very easy! Check this video that explains a couple of ways to do it: https://youtu.be/MKpStmvxkDA?si=ZQ5kMHV_GlPzJCn1
