ROS 2 GoPiGo3 Robot Humble Dave Doing Navigation

GoPiGo
, , ,
1

For the last two years, I have been trying to catch up to @keithw and his Finmark GoPiGo3 ROS robot, using the latest ROS 2 Long Term Support version named Humble Hawksbill.

I had to convert the ROS GoPiGo3 node to ROS 2, while learning ROS 2, then learn how to install, configure, and launch the ROS 2 mapping/localization package SLAM-Toolbox and the ROS 2 navigation package Nav2.

ROS 2 nodes can reside on any computer running ROS 2 on the same network, and many people run the processor/memory intensive nodes on their laptop or desktop computers which in my book turns the robot into a remote controlled car. My goal has always been to create a totally autonomous ROS 2 GoPiGo3 robot, and the recent upgrade of my GoPiGo3 to a Raspberry Pi 4B with 2GB of memory has proven up to the challenge.

In this first test of “running it all” on Humble Dave, he loaded all four cores to the max at peak load of 7 and averaging 3 to 4. (4.0 means all four cores are executing code 100% of the time with no swapped out code waiting a turn.) Memory wise, Dave used 770 MB of physical memory which suggests his former Pi3B+ would not have been able to run everything.

Here is a 3 minute video showing Humble Dave performing autonomous map building and navigation:

2 Likes
2

That is really great! Congrats @cyclicalobsessive!

2 Likes
3

Oh, I think you passed me long ago. If it looks like I’m ahead it’s only because I’m a full lap behind :slight_smile:
/K

2 Likes
4

And here’s a post showing Humble Dave telling me “I’m sorry, I can’t do that.”

All I asked was for Dave to navigate to {1.0, 0.0} - just drive forward 1 meter… any obedient GoPiGo3 knows how to do that!



No Dave, that is not 1 meter…

IMG_5148
IMG_51481920×1440 111 KB



“Goal failed” … you didn’t need to announce it.

IMG_5149
IMG_51491920×1440 676 KB



Yes sir, we traveled 740 mm (or pretty darn close):

IMG_5150
IMG_51501920×1440 654 KB


Dave “thinks” he traveled 740 mm and guess what - he is correct, but the whiz-bang navigation tried for several minutes to reach {1,0} first by wiggling the heading 1deg left then 1deg right for a while. Then he decided to try a different approach turning 90 degrees and driving a little, but then returned to the same wrong spot. Next he tried backing up 20 or 30cm and then returned to the same wrong spot and then he declared he was giving up.

Well, I give up on ROS (at least tonight)…

Every GoPiGo3 knows how to drive 1m to within a few millimeters without pegging the processor load for several minutes - Humble Dave is humiliating me.

2 Likes
5

Well that’s weird. I look forward to seeing what you figured out.
/K

2 Likes
6

Right now Dave is watching paint dry … it seems. Instead of sleeping in after a late night discovering Dave’s “failure”, I awoke early to try various hypotheses:

  • Maybe navigation was commanding a speed lower than Dave could drive?
  • Maybe navigation was commanding a speed lower than Dave could rotate?

I checked my “Dave Spec Sheet” and noted I had an entry “Sneaky Dave 0.001 m/s linear” - and sure enough when I tested it this morning: 10mm in 10 seconds! Dave can creep along at 1mm per second.

Testing turns is harder and Dave’s spec sheet only has 1 rad/s “normal” (57 degrees/second) and “max” 4.8 rad/sec (275 deg/s rotation). So how do I find his minimum?

I cranked my teleop_gopigo3_keyboard turn speed down to 0.002 rad/sec and measured how long it took for Dave to turn 90 degrees: 12min 57seconds which works out to 0.00202 radians/second !!!

I am so impressed by GoPiGo3 Dave, but my “woke up early ah-ha theory” is shattered. Following that theory had led me to a mental philosophical debate about what should a robot do when commanded to move at a rate slower than the robot can comply?

Should it move but at a faster rate, or should it ignore a command beyond its capabilities? (Implies adding self-awareness to the robot node)

Should the commanding program be advised not to command this particular robot for a speed it will not be able to perform? (implies setting a robot-specific parameter in the generalized planning node)

Should the planner be advised to wait longer for this particular robot since it cannot go as fast as commanded? (again implies setting a robot-specific parameter in the generalized planning node)

The planner is running closed loop - command a speed until a goal is achieved before a timeout, but the commanding message has no mechanism for the robot to respond “I’m sorry, I cannot go that slow / that fast.” And then into a line of thought: “Ask the robot to describe its limits” to adjust planner behaviors to the specific robot.

Shot that whole theory and debate down. Now its time for my Monday exercise - maybe I’ll come up with another theory while I’m run/walking. (My wife always tells me “Be Careful” as I go out the door, because she knows I’ll be exercising totally distracted by my thoughts.)

UPDATE: Just spotted a condition test in Nav2 Behavior Tree “IsBatteryCharging” - now that is interesting, and saw mention that the Behavior Tree controller is running a “blackboard”. Way back in 1987, I was developing “Blackboard Knowledge/Rules-Based Expert Systems” for aircraft path planning for radar avoidance and in 2010 for “Cancer Patient Medication Safety”. Good to hear the architecture is still in vogue.

2 Likes
7

Saga To Lose Sleep Over:

Navigation documentation says “To use custom nav2_params.yaml”:

ros2 launch nav2_bringup navigation_launch.py params_file:=<full/path/to/config/nav2_params.yaml>

So I created my_nav2_params.yaml with a lower maximum velocity to keep Dave from occasional doing faceplants and tried the command:

ros2 launch nav2_bringup navigation_launch.py params_file:=/home/ubuntu/HumbleDave/ros2ws/my_nav2_params.yaml

…BUT Dave still raced to the goals at 0.26m/s. Clearly not using my_nav2_params.yaml

Frustrated, I posted at robotics.stackexchange.com where good people post ROS questions.

Since no one was responding to my question, I decided to take a look at the source code for navigation_launch.py and noticed the params_file declaration appended “bringup_dir” to the passed string. Oh, boy - that’s not going to work as documented. The only way that will work is if I put my params file into the official ROS2 Nav2 share location, and rather than pass the “full/path/to/config/nav2_params.yaml”, I need to just pass the file name.

That sure sounds like an “issue” to me, so I filed an official issue on the ros-planning/navigation2 github site. It takes quite a bit of research to supply all the configuration information requested and I wrote it all up very complete.

To my surprise the Nav2 “God Himself” Steve Wacenski closed my issue saying “I noticed you posted on stackexchange. People don’t cross post.”

He obviously didn’t bother to read even the title at either location, and couldn’t be bothered to consider my question nor my assertion of an issue.

I discovered that the nav docs also suggest “robot developers” to build from sources in a <your_robot>_nav2 package, rather than following their “install from binaries” steps. This would indeed make the navigation_launch.py work (and the documentation wrong).

Oh well, I didn’t want to put my file into the share - probably will get deleted by the next Nav2 update, but I need to workaround the “ROS 2 Gods”

$ ./confirm_nav2_params_file_in_use.sh 

*** USE WITH NAVIGATION RUNNING TO CONFIRM GOPIGO3 NAV2 PARAMETER FILE IS IN USE
ros2 param get /velocity_smoother max_velocity
Double values are: array('d', [0.15, 0.0, 1.0])
** max_velocity should not be [0.26, ...]

Now to test my latest hypothesis: Will an extended timeout parameter prevent goal failure.

2 Likes
8

WTF?! What a rude response! What is the reasoning I wonder? Great way to encourage people to find bugs and give feedback…

2 Likes
9

That’s what I thought as well. Not needed in any case, but especially when he clearly didn’t even bother to read the details.
/K

3 Likes
10

Wow - that’s impressively slow. Especially Given that the GPG3 doesn’t use stepper motors.
/K

3 Likes
11

I am starting to sense the Nav2 world, from “the god’s” responses to questions and more reading of the large volume of documentation on this extremely versatile and complex package.

The approach expected of noobs:

  • Work through the Gazebo simulated Turtlebot3 Tutorial
  • Create a local <your_robot>_nav2 package ← MANDATORY for success, docs use “recommended”
  • Simulate your robot in Gazebo with <your_robot>_nav2 package using default parameters
  • Simulate your robot in Gazebo with your test-map … using default parameters
  • Run your physical robot with <your_robot>_nav2 package using default parameters
  • Change one parameter at a time, loop until stumped
    • Simulate your robot in your test-map in Gazebo … using the changed parameter
    • Run your physical robot … using the changed parameter

And only after that, ask your questions, include a log.

My “avoid all simulation” attitude is a personal problem I need to get over.

I also sense I need to go back to the former SLAM-Toolbox step and complete the following:

  • Map an area and Save Map (I have this figured out, just have not created a “Test Area Map”)
  • Run SLAM-Toolbox in Localization-Only mode (need to learn how to do this)

and then proceed through the “with your test-map” Nav2 steps above.

90% of the questions appear to be “My robot stops short of the goal” which is exactly my experience and the result of my reading suggests:

  • Tuning will allow getting closer to the goal pose, but do not expect (do not even try for) perfection
  • Tuning may allow getting closer to the goal position, but goal heading is even more difficult to achieve.
  • The tighter one tunes for goal perfection, the less tolerance for obstacles will be.
  • Multi-goal paths require even more complex tuning in the presence of dynamic obstacles
  • Using an external path planner with nav2 will result in a “clash of wills”

And to think I thought I could “Learn ROS in Four Days” … maybe four life-times.

3 Likes
12

Keep at it but set expectations. The fact that many others have the same challenge sadly means it will be really hard to achieve. Still, a difficult goal can be a worthy goal!

3 Likes
13

I look forward to your Hands-On-ROS Chapter 9 report and how closely the ROS Melodic/Noetic navigation gets to the the goal pose.

This was @KeithW 's experience. I need to go back and re-read it.

3 Likes
14

Will do! BTW, on p 280-281 of handsonros, it mentions a 5 wire modular connector between the LIDAR sensor and the control board. What control board is it talking about because I thought the only connection to the LIDAR was via USB to the Raspi?

Also, I have read elsewhere that the Raspi does not provide enough 5V power via USB to this LIDAR. What has been your (all you out there who have tried this LIDAR) experience?

3 Likes
15

Power Options for the YDLIDAR X4 Moved to:

3 Likes
16

Thanks for moving this to a new topic!

3 Likes
17

Ask me about my “New Remote Control Robot” project. . .

It’s still not done and the furor over locking down a game controller behind a certificate based connection when using a browser is still raging over at the various W3C forums.

The APIs for using a game controller as an input device via a browser interface keeps moving around until it looks like one of your mapping sessions!  Translation:  What I wrote today isn’t guaranteed to work after the next browser update.

Yup.

Been there, done that, have an entire fashion line of T-shirts!

2 Likes