Ticket #22 (closed feature: implemented)

Opened 4 years ago

Last modified 21 months ago

BlackBoard Logging

Reported by: tim Owned by: tim
Priority: major Milestone: 0.4
Component: Fawkes Version:
Keywords: BlackBoard, Logging Cc:
Git Branch: timn/bblogger

Description

Implement BlackBoard Logging (copied from #11):
There has to be a logging facility to record each change in the BB. We do not want a log writer process that comes every n msec and stores the data which is in the BB at that time. This could possibly loose data. Rather we want the data to be written to the log if it was just written via the interface. By putting the logging facility in the BB we can guarantee that no data is missed.

All data written must of course carry precise times, especially precise time offsets to the data written before so that the data is restored at the right time when it really was written to the BB (of course this cannot be guaranteed as readers may have aquired the lock at the exact time when the log data has to be restored, but we should be as close as possible with writer preference in the read/write lock).

The written data has to be versioned (and thus the interfaces have to be versioned). If the interface is changed later on the old log must still be usable by the log player. To reduce the amount of code interfaces have to be designed carefully such that these changes are not needed later on. An alternative might be to have one log-converter that converts log from any format to the current format (better option, faster during runtime).

The data is written byte-efficient, not textual representation is written. This is done for several reasons:

  • It is faster in writing, writing just the C-struct is much faster than creating and writing a textual representation (which is likely to eat more bytes)
  • It is faster in reading. The struct can just be copied from disk to local memory without any parsing from the file.
  • The files are likely to be smaller.

One of the major shortcomings here is the dependency of the endianess of the underlying system. A file created on a big-endian system will most likely not be readable on a little-endian system. Since we only use machines of the same endianess (robots and developer machines are all little endian PCs) this does not matter to us at the moment. There should be a least a flag in the log header denoting the endianess. If the times shows that this is needed a converter can easily be written then.

Change History

Changed 4 years ago by tim

  • type changed from defect to feature

Changed 2 years ago by tim

  • milestone 0.3 deleted

Removing milestone, time frame is unclear at this point in time.

Changed 2 years ago by tim

  • owner changed from AllemaniACs to tim
  • status changed from new to accepted
  • milestone set to 0.4

Required soon for some data recording so it has to be done anyway. Branch will be timn/bblogger within a few weeks.

Will be implemented as plugin which can record any number of interfaces configured similar to the way behavior engine or world model interfaces are defined. Might need different recording strategies (e.g. blocked writing or copy'n'queue). Details yet have to be specified.

Changed 2 years ago by tim

  • gitbranch set to timn/bblogger

Changed 2 years ago by tim

  • status changed from accepted to reviewing

Has been used for Nao experiments in Graz an apparently has worked, thus will only put this up for review shortly.

Changed 21 months ago by tim

  • status changed from reviewing to closed
  • resolution set to implemented
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Subscriber, Participant

  • Fawkes Trac List(Always)
  • Tim Niemueller(Reporter, Owner, Participant)