without Type Code Rep. with Type Code Rep.
storage payload file size overhead file size overhead
footprint (bytes/event) (bytes) (bytes/event) (bytes) (bytes/event)
None 0 480.000 48 520.012 52 Octet1K 1024 11.320.000 108 10.840.064 60 Octet100K1 102400 102.508.000 108 102.460.064 60 Odometry 44 5.840.000 540 1.000.508 56 RangeSensor 1460 18.520.000 392 15.160.352 56 SharedBelief 1268 28.799.996 1612 13.241.576 56
Table 8.4: Logging storage footprint for 10,000 entries.
The 60 additional bytes of overhead for the Octet1K payload are caused by encoding the data type. For every event, the complete type description of the payload is stored. This is unfortunate, as usually a small set of event types are sent hundreds or thousands of times via the event channel. The type code can easily exceed the size of the actual payload for small payloads like odometry events. Also the type description accumulates to more than 1 KB for the SharedBeliefState01 data structure. Even though this does not seem to cause a significant performance overhead, the size overhead is still significant. Unfortunately, the use of complete type codes is hard to avoid in a generic logging facility based on the CORBA::Any data type. But, there is no need to store type codes repeatedly within the log file. So rows five and six show the file size and overhead achieved by using a type code repository that is prepended to the event stream and contains the needed type codes. The type code in the log record is replaced by its id in the repository. This way the size overhead can be kept constant and within an admissible range. The use of the type code repository yields the same runtime performance within the precision of measurements.
8.4
Prioritized Video Image Processing
A critical part of robot vision is the timely processing of image data. The VIP framework does not try to provide faster implementations for standard image operations, as sufficient libraries for this purpose exist. These can be easily utilized for the use by VIP, as done for IPP in our applications. Instead this framework concentrates on improving the responsiveness of a vision application, by allowing for proper priorization and synchronization of image processing tasks with parallel and asynchronous control flow.
A typical use case for the processing of multiple filter trees, is the combination of a fast path with an asynchronous slow path of vision processing, which then needs correct priorization. We therefore assess in this section the capabilities of the framework to correctly preserve processing priorities under high-load situations.
106 CHAPTER 8. EXPERIMENTAL EVALUATION
Prioritized Unprioritized Processing tree
Mean Std. Dev. Mean Std. Dev. Fast path only
fast path 7,17 0,035 7,18 0,052 Medium load fast path 7,22 0,017 7,26 0,479 slow path 1 30,46 25,197 8,32 10,000 High load fast path 7,22 0,025 8,55 3,192 slow path 1 53,31 69,921 60,77 94,601 slow path 2 57,66 5,065 56,84 5,240
Table 8.5: Different timing statistics for the individual processing trees in both, the prioritized and unprioritized case. The values are stated in µsec.
The typical scenario would be one camera-synchronous processing tree that runs at full frame rate and extracts sensory information for the reactive control module and one or more asynchronous processing trees, that are connected to the data flow of the first tree and perform time-consuming computations not possible at full frame rate, extracting information for higher-level cognitive processes with relaxed timing constraints.
The configuration of the
Worker 2 Asynch Camera Worker 1 low priority high priority Asynch Worker 3
Figure 8.3: The filter configuration of the experi- ment.
VIP module for this ex- periment consist there- fore of one high prior- ity tree with the cam- era as source node, run- ning with a round robin real-time scheduler (the fast path) and one, resp. two low priority asyn- chronous processing trees that are connected to the camera tree, running with default priority (the slow paths). The config- uration is illustrated in Figure 8.3. The low priority load is increased incre- mentally in the experiment. In the first run, the synchronous processing tree is run alone. In the second run one low priority processing tree is added to the configuration, but still all processing threads can be completed at frame rate (30Hz). In run three a second low priority tree is added and the system load reaches saturation. The results are compared against the equivalent setup without priorization.
Table 8.5 shows statistics on the overall time, the different processing trees need for completion. In the unprioritized configuration, the completion time of the camera-synchronous tree drops significantly in the third configuration, as the thread is preempted before completion to perform work on the other
8.4. PRIORITIZED VIDEO IMAGE PROCESSING 107 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 20 40 60 80 100
fast path only medium load high load 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 20 40 60 80 100
fast path only medium load high load
Figure 8.4: Timings of the fast path with none, one and two slow paths running concurrently. The left plot shows the unprioritized case, whereas the right plot shows the fast path running with enabled real-time scheduling.
processing trees. This would cause significant delay for the consumers of this sensor information (e.g. the reactive control unit).
In Figure 8.4 this effect is illustrates by plotting the individual timings for 100 runs of the fast path. It can be clearly observed that while the prioritized processing three still runs with predictable completion time, the timings of the unprioritized configuration worsen significantly under high load.
Another visualization of these preemptions is shown in Figure 8.5. From the third setup a small section of the interleaving processing of the three processing trees is plotted. Each tree is assigned a different color. Yellow was chosen for the fast path, the slow paths are colored red and blue. To fit into the column, a new line is added each time the processing of both slow paths is finished. The completion of a processing tree is marked with a black box at the end of the colored bar. While the real-time scheduled fast path always runs to completion before its processing stops, it is occasionally interrupted without priorization. Additional load on the system will worsen this effect. A medium complex robotics application performs many other tasks in parallel to image processing, which will contribute to the latencies in high load situations.
Prioritized fast path:
Unprioritized fast path:
Figure 8.5: Illustration of alternation between the different running processes with a prioritized resp. unprioritized fast path.
108 CHAPTER 8. EXPERIMENTAL EVALUATION