RRT-X (dynamic obstacles)
Note: this is the dynamic version of RRT-X that is capable of handling moving obstacles (the task for which it was designed). A version for OMPL also exists, but only handles static obstacles (see below).
My RRT-X code is written in the Julia language. Why? As a research scientist I'd rather spend my time developing new algorithms than micro-managing data structures and worrying about low level memory management. I also need things to run relatively quickly. Julia provides a nice blend of high level coding and execution speed.
That said, this code will not run as fast as if it were written in C (see note to Julia architects below). Therefore, in order to make fair comparisons vs. previous algorithms for my papers, I also implemented Julia versions of RRT, RRT*, and RRT#. You will find all of these included in the code. It also includes a few supporting data structures.
For the most part (95%), I LOVE the Julia language. My main complaint is that the garbage
collection system likes to occasionally touch all of the nodes in my motion graph (even though none of
them will ever be deleted until the end), this turns out to waste a lot of time for the
random graph search algorithms that I study. The more nodes in the graph, the
more time is wasted. I (kind of) raised this issue
but, admittedly, neglected to include more background.
As I understand it, the only way to prevent Julia from checking one of my graph nodes
would be to declare it as an immutable type. However, this prevents any of its values from
changing (and my nodes' values need to change to reflect new graph
connectivity and better cost-to-go/goal values stored at each node).
The best work-around that I have found is to toggle garbage collection on and off at
a few computational bottlenecks. This does not remove the problem, but reduces it.
My biggest wish for future versions of Julia is a way to tell the garbage collection
system to remove something from its consideration, assuming that I will manually delete the object.
From a language user's point of view,
I see this working along the same lines as Julia's typing approach:
I can ignore this form of micromanagement when I don't care about performance, but I have
more control in the few cases that performance is critical.
I suggest starting by looking at the README.txt file.
Collision detection is implemented differently for each type of obstacle that is currently included (mostly 2D shapes like polygons and balls). Keep in mind that this is prototype code, if you have a different type of obstacle then you will likely need to implement collision checking routines for it. keep in mind that RRT-X is designed to handle dynamic (unpredictably moving) obstacles. This is one reason dynamic RRT-X cannot currently be implemented in many off-the-shelf planning frameworks, such as OMPL, that use a brute-force approach to replanning (e.g., start over from scratch).
RRT-X (static obstacles)
Note: this version of RRT-X only handles static obstacles (not what RRT-X was designed for, but still useful if that is what you need). The original version for dynamic obstacles can be found above.
Here is the latest version on GitHub: OMPL with RRT-X static.
More information can be found at: CForest Parallelization Framework. Check out their charts showing the awesome speedup!
Light-weight driver for iniLabs DVS128 retina sensor
The iniLabs DVS128 retina sensor is an event based imaging device. It is really cool. However, when working with one I had a terrible time getting access to the raw device data in any way that was useful for writing my own code. Thus, I modified an existing driver for the task. The result is a minimalist's version of the driver in both C and Java, both include examples of how to read data from the device.
Field D* with improved path extraction
License: GNU GPL v3
Alternatively checkout from the Prairiedog Google Code Repository:
There are two ways to use the code: C/C++ and ROS (Robot Operating System). There is no official documentation beyond the next few paragraphs, but the code is fairly well commented.
In the include directory you will find all of the files necessary to compile and run a working demo in C. The top level files are fielddstar_gradient_extract.c and fielddstaroptimized_gradient_extract.c You can change the functionality by editing the main() function and/or modifying the global variables at the top of these two files. If you want graphical output then I assume you have opengl installed (if not, you will need to comment out a flag at the top of whichever of these two files you are compiling, but C++ can then also be used).
The rest of the code is organized as a ROS package that wraps the C code and adds some functionality for map dilation. I just pounded my original C code into a ROS node, so some things like naming conventions are a little awkward. This could be annoying if you are interested in overhauling the code, but small changes should be fairly simple. The ROS node (base_planner_cu) is part of the prairiedog system/platform I helped to develope at Correll Lab. Go here if you want the whole thing---useful for seeing how the different nodes work together (i.e. mapper_cu is in charge of sending all of the data that base_planner_cu uses).
License: GNU GPL v3
Download: Prairiedog Google Code Repository
The prairiedog platform is a lightweight robotic platform built on top of the iRobot Create Platform. I developed the software for prairiedog during my PhD. The code is written in ROS, but is probably a little dated at this point. More documentation can be found at wiki.ros.org/prairiedog.
Copyright 2008-2019, Michael W. Otte