Changes between Version 2 and Version 3 of WikiStart/OngoingWork/RockDiagnostic

12/01/14 23:50:02 (5 years ago)



  • WikiStart/OngoingWork/RockDiagnostic

    v2 v3  
    1212 - wifi link status (drivers-orogen-wifimon) 
    14 Ideas 
    15 ------------ 
     14== Ideas == 
    1616Simple metrics could already help tremendously: 
    1717 - ratio of received samples vs. rejected samples in the stream aligner 
    2424Among more complex things that can be done: 
    2525 - given the shape of the dataflow network, one can look at how latency propagates using the stream aligner and the sample frequencies, and pinpoint possible causes. This requires some analysis, but would be really cool. In addition, using the CPU data, it can propose hypothesis on whether the problem comes from starvation CPU-wise or lack of samples (driver /filter problem). 
     27== Other things == 
     29The reliance on log files is really an issue, as it is not formalized (and therefore hard to analyse automatically). The two biggest issues that make log file reading mandatory currently are: 
     30 - we know if a hook fails, but not why 
     31 - we know that a component goes into EXCEPTION but not what the exception is 
     33The idea there would be to extend the current notification API (which is currently only an int) to an API where both a symbol (what) and a data structure (why) can be sent. Ideally, it would mean that the notification output port (currently the ill-named "state" port) would be a discriminated union (e.g. from boost). We would have to add support for these in orogen. This support could be done with the current means by creating our own "discriminated union" intermediate type and present the boost union as an opaque. Our own discriminated union would simply be: 
     36struct TaskNotifications 
     38   NOTIFICATIONS type; 
     39   std::vector<NotificationData0> data0; 
     40   std::vector<NotificationData1> data1; 
     41   ... 
     45One downside of this is that this notification API would not really be usable on the C++ side (every component would have a different notification port). So far, not an issue for Rock, though. Ideally, we should be able to implement it as an orogen plugin, and use the opportunity to add a base::Time field. 
     47With such a discriminated union type, we would lose one pointer per possible data type, but it is IMO not such a big deal and has the merit that it can be implemented right now (I think).