|Please ask about problems and questions regarding this tutorial on answers.ros.org. Don't forget to include in your question the link to this page, the versions of your OS & ROS, and also add appropriate tags.|
Introduction to Ecl DevicesDescription: Introduces the general framework for ecl devices.
Keywords: ecl devices
Tutorial Level: INTERMEDIATE
Next Tutorial: Serial Devices
All devices have both RAII and non-RAII setup methods. In practice, this means you either bundle all configuration into the constructor, or you utilise the open() method to do configuration yourself. Usually RAII is the more ideal approach, but sometimes its inconvenient so the latter method is also available. For example, the serial class:
Cleanup is always done in the destructor, though if you need to manually open/close a device frequently, a close() method is also provided.
Some class are output devices (only write), others are input devices (only read) and some can do both. The read and write modes will sometimes be configurable, (e.g. timeout or non-blocking for serial reads), however the actual read and write operations will always be the same.
Exceptions (enabled by default) will be thrown in most functions for errors which are not likely to be used in a fast control loop. Constructors, open and close, configure methods etc. Others, such as read and write calls will throw exceptions only in debug mode.
When exceptions are not enabled, or running in release mode, error flags can be checked in the return values for most of these functions. Refer to ecl_exceptions for more information.
Essentially, a device class can be written in any way you please. However, if you wish to connect it to higher level components, in particular, streams, you must ensure you class satisfies certain device concepts. Refer to ecl_concepts for more information.
This is the logger class. Since its primary purpose is to serve logging, the option to make it seekable was dropped to keep it nice and simple.
The most important thing to note with the serial class is that it really doesn't implement much of the underlying api. Rather it wraps a configuration appropriate for control and keeps it as simple as possible. Of the possible read modes, it utilises only a timeout mode and a non-blocking mode. The other modes generally do not work very well at the speed that control loops need to run.
This is a virtual device used for storing and converting strings (similar to Converters, but more general). It is not intended for direct use, but as a mechanism for the stringstream class which functions very similarly to the c++ stringstream classes.
These are a very simple/rough implementation of ipv4. It isn't designed to be an industrial strength tool - just something for simple cross platform connections to enable quick and simple remote debugging program builds (or similar).