-
Notifications
You must be signed in to change notification settings - Fork 1
1 User Facilities
A Skinware user is an application that acquires data from Skinware. This means services that acquire data from Skinware are also a sort of user and use the same mechanism to receive the sensor data. Users attach to drivers, and maintain a local replica of the robot skin. If a driver leaves Skinware, for example to restart or permanently, the user has the choice to stay attached, in the hope that the driver will come back representing the same robot skin, or to detach from that driver, and attach again to it when and if it comes back. This really depends on whether the user application is able to deal with dynamic changes in the robot skin or not.
While it is possible for the user to attach to specific drivers it requests, Skinware also allows the user application to simply attach to all drivers available. Furthermore, the user application could either detach from specific drivers, or detach from all bad drivers altogether.
The driver and user interfaces use Skinware services underneath. The drivers spawn writer threads while the users acquire data with reader threads. The reader threads can be spawned in three modes of operation.
- Periodic
- Sporadic
- Soft
Skinware also grants access to not only the sensor data, but also the modules and patches of the skin. For a general application, these entities are likely not interesting. If you are interested, please the drivers tutorial for an explanation of what these entities are.
A periodic reader synchronizes and acquires sensor data from the corresponding writer with a given period, which is not necessarily the same as the writers. It cannot, of course, be faster than the writer. With this method, the user application reads sensor data from available data structures, assuming they are updated periodically.
Note that with these readers, there is no synchronization between the user and the reader threads. The reason is that with synchronization, it would not be possible to guarantee that the reader thread is executing in real-time and strictly within its execution period. For synchronized reads, see below on sporadic readers. This lack of synchronization implies that the sensor data could get updated during their processing, which means your application would need to be able to cope with that.
Sporadic readers perform data acquisition upon request. In this mode, the user application can request new data from some or all drivers and then proceed with their processing. Unlike periodic readers, in this case the sensor data remain unvaried during their processing.
Soft real-time readers are not periodic, but automatically acquire the newest data whenever they are given a chance. These readers are signaled by their respective writer, at which point the scheduler could run them at any time it sees fit. In a system with light activity, this in fact could result in minimal data transfer delay as the reader could potentially wake up immediately after new data is available. As a soft real-time thread there is, of course, no guarantee.
Skinware maintains disjoint data structures relating to different drivers, and pieces together these data structures to show a combined view of the robot skin to the user application. To avoid having the user deal with such complexities, Skinware uses callbacks to iterate over specific entities, such as all sensors, sensors of a specific type, modules, patches, etc. If you are developing with C++11, see the respective tutorial to see how lambda functions can be used.
Next: See user's interaction with Skinware for how the above operations translate to code.