Simple Exploration Example

[slowrunner]

Carlitoselmago asked in iRobotEducation/create3_examples#35 (comment) for

an example of a basic aproach[sic] to exploration, something like SLAM but without lidar? just something that works with the default sensors of create3 (bump, ir)

This topic, "robot autonomously exploring to gain an awareness of its environment and itself relative to that environment", is of great interest to me. There are many theoretical philosophies, strategies, and tactics written about but only a few have been packaged for the ROS community to use. Beyond the complexity of the specific implementation, comes generalizing, packaging for release, and dealing with support/maintenance. This is where "Open Source Software" as a concept can explode.

iRobotEducation has created an example of "exploration", the coverage server, which indeed implements an exploration strategy but does not "map" nor "localize". (It also is not parameterized for "obstacle clearance limit" which results in unexpected/unprotected collisions of objects mounted on top of the Create3 with the environment.)

I came to ROS to avoid having to re-invent software for common robot functions, especially for complex functions that I lack the ability to follow the matrix math and statistics required to implement the functions. Mapping, Localization, and Navigation are specifically those first functions I want to leverage the work of the surprisingly dedicated ROS community.

The ROS community has used the strengths of the 2D LIDAR for input to those three robot functions (Map/Localize/Navigate) with the SLAM-Toolbox/Nav2 packages which all operate with a standardized definition for maps, and there seems to be early gathering around RTABmap with 3D visual input (RGB with depth from stereo images or 3D LIDAR point clouds).

Since the output of the 2D LIDAR for input into those packages is the /scan topic, I created an ir2scan node which converts the seven Create3 IR INTENSITY sensors to seven range estimates and publishes them as a /scan topic which when fed into the slam-toolbox was able to generate a crude map. My inexperience with the slam-toolbox and nav2 did not result in successful localization and only partial success with the navigation package.

Map created by Create3 IR Intensity sensors using ir2scan node with slam-toolbox:

I also created a map from my home floor plan but again my experience with slam-toolbox and nav2 prevent me from investigating if localization is possible using my Create3 "estimated range scan". I read a research paper about a localization method that used heuristics about a home (e.g. wall angles are usually 90 degrees) but nothing like that has been made available in a community supported package.

Map created from home floor plan, used with Create3 unlocalized /odom:

It is obvious from that "dead-reckoning exploration" how important localization will be for autonomous exploration and navigation.

Sadly, I do not believe a generalized "basic SLAM without additional sensors" is of interest to enough ROS folks, with the skills to create such, to exist already. One of my prior robots, Cye (1997), used a priori knowledge that its home base was near a room corner which it used to reset its /odometry origin and heading before and after every expedition off the dock. It was able to map my home, and navigate using dead-reckoning in the map it developed. It also left terrible perforation marks in the carpets and was returned for this issue.

Theoretically, having a known quality map from a floor plan published by the slam-toolbox map server, with a "keep out zone" list and "kitchen zone, dock area zone" list, combined with a "follow wall on right/left for x distance", (including a follow keep out zone "wall" could be combined with a periodic "localize with Create3 proximity/bump sensors with a designated zone feature such as a wall for single dimension localization and heading localization, or a corner for both x,y dimension and heading localization ...

BUT turning that concept into a generalized, documented, supported package does not appear to interest more than you and me.

My Create3 Wall Follower Looking For Intelligence, WaLI, can "play" for 3.3 hours with no sensors powered. Powering an Oak-D-Lite camera in standby reduces that playtime to 2.9 hours, and actually running the camera doing stereo depth and object recognition along with the RTABmap program reduces the playtime further to 2.25 hours (estimate).

So far this "all up" configuration causes seizures in the Create3 preventing successful vSLAM, but there is a "Create3 topic republisher" in development that may enable vSLAM on the Create3 as my preferred map/localization method which will then enable nav2 navigation and object avoidance.

[carlitoselmago]

Thanks for sharing all that information

[slowrunner]

I love your "curiosity driven exploration" based on new images.

This has been a back of the mind project for me since 1987. At that time, I was working with reasoning on knowledge bases arranged as "concept graphs" and later applied it to sensor fusion for route planning. For the last ten years I have been wanting to have my robot explore my home, aware of its pose, to snap pose-tagged-images with the intent to spend its non-playtime, processing the images for known and unknown objects. Perhaps new relationships will be discovered between known objects, and the unknown objects become "learning targets" to expand the robot's knowledge base, for deepening the conceptual graph, through dialog with humans at first, and eventually integrating some form of automated Internet search with lower confidence on the added concepts.

The RTABmap mapping and localization package actually works on a similar feature and pose tagged image graph concept.

Google supposedly has built a household image database, but having started my programming in the 8-bit assembler days I have a serious case of NIH (Not invented here) that always makes me want to build rather than re-use. Many times the investment to learn how to reuse, and design of workarounds for the packages' limitations seems greater than the effort needed to do it myself, and many times the package support is lacking or behind a pay wall. Additionally, I am just enamoured by autonomous robot reasoning.

The Create3 could be a platform to allow thinking about the environment and stop thinking about the robot. I have spent forty years building robots and dealing with the robots' limitations; I really want a platform that I don't have to spend all my time building robot functions or work-arounds for platform limitations. I am hopeful but still dealing with wrangling the Create3.

[carlitoselmago]

I do definitly share the NIH scenario, didn't know about the concept!