- Collection of cmake/make build tools.
- Cross platform library for linux, mac, win (long term goal, priority is for linux).
- C++ interfaces where speed is first priority, convenience second (we dont sacrifice speed for convenience).
- Designed with a focus for control systems.
The ecl was motivated by the need for higher level control algorithms (in robotics) adapted to a wide variety of reasonably low-performance hardware. In other words it had to be scalable, cross-platform and fast.
Fast : it is a collection of useful cross-platform build tools and lightweight cpp classes ideally targeted for embedded platforms.
Cross Platform : the build tools are intended to facilitate the process of cross-compiles where cmake is the workhorse. The cpp classes are designed to provide a common denominator across platforms (in much the same way that Qt does), but are designed with an emphasis on speed and targets control systems applications. Cross platform functionality is very much a work in progress though and currently only fully supports linux.
Scalability : these tools can be used like a standalone library with a few cmake modules, but when used with the ros build environment (regardless of whether you are building ros apps or not), they provide a very convenient way of managing a (cross-compiling) build environment - dependencies, link flags, cflags, toolchain variables are automatically managed and a single command can be used to (cross) compile a whole suite of libraries/applications at once.
Until recently, where speed mattered, c was used and where convenience mattered cpp was used and very rarely did the lines cross. However control systems are becoming increasingly complex and abstract structures are needed to manage that complexity. Coupled with the burst of mini computational platforms that have recently become available (e.g. the intel atom) a good case for the use of a cross platform cpp library in embedded programming becomes apparent.
Qt is a good reflection of this need and provides a very good cross platform solution, but is designed for user interfaces, not control and this often reflects in the design and speed of the api. Boost is another option, but various components can be heavy or arcane (does not produce very readable code) and sometimes not ideally targeted for control.
The ecl was originally driven to find solutions that solved the shortcomings in existing libraries. It was conceived at Yujin Robot, where practical solutions for control in a robotics environment were needed to be implemented on a wide variety of platforms - win, linux and apple.
We don't wish to reinvent the wheel, so we still use as many existing alternatives as we can - for example, the boost smart pointers library is irreplacable. However for others, a redesign was needed - e.g. for sigslots, we needed a thread-safe implementation, as well as a more convenient means of connecting signals and slots. Other components of the ecl are entirely new, often targeting oft used constructs in control or robotics.
What the ECL is Not
The ecl is not a library of algorithms - it is designed just to provide convenient c++ interfaces for common structures. A key concept for us - if we find ourselves utilising common code across algorithms, then we put it in the ecl.
The library gets fully road tested on a variety of platforms at Yujin Robot, from robots running very low level embedded arm cores to mid-range intel atom control platforms or pc development simulations. This helps shape the library to fill the needs of a practical environment.