A new side experiment: a standalone sandbox for experimenting with generative systems, in the form of a basic UI for Interactive Evolution. Currently there are implementations for a few generative systems:
- A 2D version of Karl Sims's Virtual Creatures
- A Cell Lab-inspired system
- An original, yet very basic system ("Segment Tree")
This new sub-project is located under experimental/replicators, and a WASM build
can be found here
(note that this build is significantly slower, and less stable, compared with
the native builds)
The new notebooks subdirectory contains a few examples of using Darwin's
Python API as Jupyter notebooks. Thanks to Binder,
interactive version of these notebooks are one click away.
Darwin is now on PyPI: https://pypi.org/project/darwin-framework !
This means that if you're on Linux or Windows (sorry, no macOS packages yet), getting it is as simple as:
pip install darwin-framework
Python bindings are now supported on Windows (MSVC++) too.
Experimental Python bindings!
Currently available only on Linux, check out the setup instructions and a basic intro / tutorial.
Last year I gave a talk about the Darwin Framework at a Seattle area C++ meetup. Here is slide deck I prepared for the talk, in case anyone is curious.
It took a bit longer than expected, but the car version of the race track domain is here. The car controls are more restricted compared to the drone and this variation seems quite a bit challanging. Both CGP and NEAT manage to evolve reasonable car controllers (the capture below is NEAT after ~350 generations)
A small detour through the land of splines and generating random race tracks. The new implementation is significantly more robust (ex. no more self intersections for complex tracks). The spline & outline offset computation is now encapsulated in math::Outline.
Spline sampling before and after implementing equidistant points (before/after):
The new math::Outline based implementation results in much cleaner tracks:
drone_track is a new domain starring the drone, this time racing around a track.
Consistent with the rest of the built-in domains implemented in Darwin, the test tracks are procedurally generated, which means that the trained model can't simply "memorize" the track layout and has to generalize (procedural environment generation proves to be a great answer to overfitting)
Another drone-based domain: drone_follow. Follow another drone which moves on a random path (keeping a fixed distance). The only inputs are drone's sensors (camera plus optionally touch, compass or accelerometer sensors)
New domain: drone_vision created using the new sim::Scene & associated building blocks (sim::Camera, sim::Drone). The agent's goal is to "simply" track a bouncing ball using only the camera pixels.
A new experimental directory is the place for subprojects which are not strictly
required in order to build & run Darwin experiment. The first such project is a simple
sandbox intended to help with prototyping 2D-physics environments.
Part of this sandbox (experimental/2d_physics), Box2D was extended with support for
minimal visual attributes (ex. object color/material) and a few sensors:
- TouchSensor: contact information
- Accelerometer: linear and angular acceleration
- Compass: heading information (in the object local coordinates)
- Camera: a simple 2d raytracer providing color and depth channels
New domain: ballistics. Given the (x, y) coordinates of the target, output the aim angle required to hit the target (initial velocity is fixed). The analytical solution is not exactly trivial and both CNE and NEAT struggle to solve this seemingly simple problem.
A new tournament implementation: Swiss Tournament
Various additions to the CGP implementation:
- CGP genotype exporter
- Support for multiple selection algorithms
- Evolvable constants
- Stateful functions
- A simple one-point crossover operator
New population: a basic Cartesian Genetic Programming (CGP) implementation.
Yet another take on inverted pendulums: this time the pole is attached to a wheel and the agent tries to keep the pole balanced by applying torque to the wheel, similar to riding an unicycle.
It also introduces an additional goal: keep the unicycle close to a random target position. This is rewarded by a fitness bonus inversely proportional to the absolute distance from the target (but only if the pole is balanced for the whole episode)
New domain: double-cart-pole. This is a more difficult variation of the single-pole balancing problem.
New domain: the classic cart-pole control theory benchmark problem (also known as "pole balancing" or "inverted pendulum")
This is the first domain implementation to take advantage of third_party/box2d. Using a complex physics engine for this problem is arguably an overkill, although it does allow a wide range of interesting variations. For example the current implementation exposes the following configuration knobs:
- world gravity
- pole length and density
- cart density and friction
- discrete vs continuous force applications
For more information, see the cart_pole domain documentation.
Adding experimental support for the Box2d physics engine (third_party/box2d).
Updating and restructuring the documentation.
Added a rudimentary support for batching experiment runs in Darwin Studio. The
"experiment run dialog" allows setting the number of batch runs (default is 1) and
also a max_generations limit:
This has the same effect as repeatedly running the same experiment variation multiple
times, and the result of each run is recorded as a separate trace pointing to the same
parent variation.
The aggregated results can be visualized using the new batch_fitness.py script.
Added core::PropertySetVariant and the corresponding support in core_ui::PropertiesWidget:
The intention is to allow sub-modules (for example multime tournament implementations) to define their specific configurations.
Initial release