Category: Nav2

Hydroponics Robot Part 3 – Mapping Issues Continued

Hydroponics Robot Part 3 – Mapping Issues Continued

Welcome back to the third part of my series on building a hydroponics robot! In this blog post, I’ll continue discussing the mapping issues I encountered while trying to navigate my robot through narrow passages and plant rows.

Increasing the global costmap

Previously, I tried increasing the global costmap to see if it would improve my robot’s alignment with the rows when it returned. Unfortunately, this didn’t seem to be enough, and the issue persisted. I suspected that the robot’s slight backward angle could be causing the problem, so I decided to try leveling it and see if it would help.

Leveling the robot

I attempted to level the robot to see if it would improve its alignment with the rows when it returned. If leveling the robot works, I may consider getting a gimble for it. However, since I couldn’t find a gimble on short notice, I ended up hot gluing two pringles can lids to the bottom of the bot as a temporary fix.

Recreating the map

Despite my efforts, I still had trouble with alignment and localization drifting. I suspected that I may need to recreate the map since different parts of the robot were having similar issues now.

Re-configuring the initial pose

I also re-configured the initial pose in nav2 so that I don’t have to keep resetting it. This should save me some time and effort during testing and troubleshooting.

Adjusting the parameters

I spent a lot of time messing around with params, but I was still unable to get the robot to navigate around a post without the localization drifting and getting stuck in a recovery loop. One config that did appear to have been missed was that the behavior global_frame was still set to odom instead of map.

Loads of trial and error, but sigma_hit under in nav2 config under amcl appeared to have significantly reduced drifting.

Repairing the tire tread

During my testing, I noticed that the tread of the tire (pvc end cap with rubber glued to it) was lost, so I needed to repair that before continuing.

Trouble navigating through a narrow passage

The robot was still hitting issues exiting a narrow passage but had no problems entering it. It actually seemed to be having trouble going from the middle of the lane to the other lane when the goal was within local costmap vision. I suspect that PathExpiringTimer may have helped with this, but I could not get it to work (probably set it in the wrong place).

I will consider writing a separate blog post about this issue. In the meantime, there’s more information about PathExpiringTimer in the links below:

And that’s it for this blog post! Despite the mapping issues, I’m still making progress with my hydroponics robot, and I’m excited to continue experimenting and tweaking it to get it just right. Stay tuned for more updates in the next part of this series!

Hydroponics Robot Part 2 – Map Resolution

In my work with hydroponics robots, I recently faced challenges related to robot localization and map resolution. After consulting with ChatGPT, I discovered that the lidar and map were not synchronizing properly due to issues with the robot’s odometry.

Fortunately, I was able to resolve the issue and the robot is now able to navigate between two lanes successfully multiple times. However, I still had concerns about the map resolution and decided to test creating the map in a higher resolution.

While this initially proved challenging, I discovered that I had been using the wrong launch file. After fixing this issue, I started with a resolution of 0.01 but found it to be too slow. I then increased the resolution to 0.025 and found that it looked much crisper than the previous 0.05 resolution. Moreover, I did not encounter any issues with the map drifting while generating it, which was a significant improvement from my previous attempts.

However, my virtual machine struggled to process the map with the local cost map and global cost map both set to 25mm. To address this issue, I plan to increase the global cost map to 50mm to see if it helps with processing.

Improving robot localization and map resolution is crucial for the success of hydroponics robots, and I am excited to continue exploring ways to optimize these processes for even better results.

Setting the initial pose using config in NAV2

While working through the articubots tutorials I have been setting my initial pose for nav2 manually using rviz2. It works but it can be a little tedious when testing changes that require frequent restarts.

Luckily, there’s a small section of config in nav2_params.yaml that you can use to set your initial pose:

amcl:
  ros__parameters:
    ...
    set_initial_pose: true
    initial_pose:
      x: -3.644
      y: -5.596
      yaw: -2.793

This means that it will default to this location when starting up.

Once you’ve configured it, you should see something like the following in your localization startup:

...
[map_server-1] [INFO] [1679645323.134873176] [map_server]: Configuring
[map_server-1] [INFO] [map_io]: Loading yaml file: /home/parallels/Desktop/dev_ws/install/my_bot/share/my_bot/maps/21_03_2023.yaml
[map_server-1] [DEBUG] [map_io]: resolution: 0.05
[map_server-1] [DEBUG] [map_io]: origin[0]: -7.34
[map_server-1] [DEBUG] [map_io]: origin[1]: -9.37
[map_server-1] [DEBUG] [map_io]: origin[2]: 0
[map_server-1] [DEBUG] [map_io]: free_thresh: 0.25
[map_server-1] [DEBUG] [map_io]: occupied_thresh: 0.65
[map_server-1] [DEBUG] [map_io]: mode: trinary
[map_server-1] [DEBUG] [map_io]: negate: 0
...

There’s a bit more info on this setup here, as well as a few notes on how to set it programatically instead.

Nav2 Localisation not Loading a Default Map

Hi everyone,

I finally have my diffdrive robot navigating with waypoints using Nav2 and this great tutorial. However, while trying to use a saved map for localization I ran into the following error:

ros2 launch my_bot localization_launch.py use_sim_time:=false
....
ocalization]: Configuring map_server
[map_server-1] [INFO] [1673064055.126698671] [map_server]: Configuring
[map_server-1] [ERROR] [map_io]: Failed processing YAML file /home/chris/Desktop/dev_ws/install/my_bot/share/my_bot/maps/chris_room_07012023/chris_room_save.yaml at position (-1:-1) for reason: bad file
[map_server-1] [ERROR] [1673064055.126801797] []: Caught exception in callback for transition 10
[map_server-1] [ERROR] [1673064055.126805589] []: Original error: Failed to load map yaml file: /home/chris/Desktop/dev_ws/install/my_bot/share/my_bot/maps/chris_room_07012023/chris_room_save.yaml
[map_server-1] [WARN] [1673064055.126811964] []: Error occurred while doing error handling.
[map_server-1] [FATAL] [1673064055.126815339] [map_server]: Lifecycle node map_server does not have error state implemented
[map_server-1] [INFO] [map_io]: Loading yaml file: /home/chris/Desktop/dev_ws/install/my_bot/share/my_bot/maps/chris_room_07012023/chris_room_save.yaml
[lifecycle_manager-3] [ERROR] [1673064055.127951438] [lifecycle_manager_localization]: Failed to change state for node: map_server
[lifecycle_manager-3] [ERROR] [1673064055.128136607] [lifecycle_manager_localization]: Failed to bring up all requested nodes. Aborting bringup.
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)

I had the following entry in my launch file:

        DeclareLaunchArgument(
            'map',
            default_value=os.path.join(bringup_dir, 'maps', 'chris_room_07012023/chris_room_save.yaml'),
            description='Full path to map yaml file to load'),

My map was also in the correct folder and valid output from the slam_toolbox plugin in rviz2. I had also run `colcon build –symlink-install`.

Initially I thought that I’d used the wrong settings in rviz but eventually I realised that the file was missing from the install directory. Despite running colcon build it was not building my new map files.

Luckily, this ended up being a fairly easy fix. I’d simply missed adding the directory to CMakeLists.txt. 

# Add maps to the end of the DIRECTORY line.
install(
  DIRECTORY config description launch worlds maps
  DESTINATION share/${PROJECT_NAME}
)

After updating CMakeLists.txt and re-running colcon build --symlink-install I was finally able to start localization with a default map.