Implement an example function that takes the data from the buffer and the saves it to a .mat file

[traversaro]

No description provided.

[AlexAntn]

I have been implementing some things about this issue, and some points came up in the meantime:

• The circular buffer overwrites the older entries when it is filled up, so we have to make sure that these entries have been read before they are deleted (otherwise we lose "frames");

  • This could happen, for example, if some latency leads to a dump of many data entries in a very short time;
  • One way to get around this is to have a thread continuously reading the buffer and storing locally the data;
    • This would also have the benefit of keeping the writing side of the circular buffer smaller and (for future implementations) independent of the file writing;

• We might need to be careful about the locks around the circular buffer. From what I understood on reading the boost implementation (maybe @Nicogene can confirm) there is no issue with multiple readers. The only issue is with reading an entry that is being written to.

  • This should only happen if the buffer is full, and it is overwriting an entry, right?

• Final point: should we clear the buffer as we read it? This would help to prevent the overwriting issues mentioned above, and it would ensure that the reader doesn't read the same entry twice. Theoretically, this shouldn't cause a memory access issue with the buffer since we are removing entries that are not being written to, but we can test.

For reference, what I am currently doing is having the readBuffer function separate from the saveToFile, and it keeps reading the buffer and saving it to a local vector until we stop the data collection, in which case it calls the saveToFile function.

[Nicogene]

In #27 @AlexAntn and I implemented the first example of usage of the API we implemented.

The next step would be to make the StoreData class a template class and maybe convert it to a function if doable.

In particular, it would be nice also to change this constructor

    storeData(std::shared_ptr<boost::circular_buffer<Record<vector<int> > > > _cb, const double& _period) : cb(_cb), period(_period) 
    {
      closing = false;
    }

to something like

    storeData(const yarp::telemetry::Buffer<T> >& _cb, const double& _period) : cb(_cb.getBufferSharedPtr()), period(_period) 
    {
      closing = false;
    }

In order to hide to the user the boost::circular_buffer implementation since it may change in the future

Opinions?

cc @AlexAntn @traversaro @S-Dafarra @drdanz

[S-Dafarra]

In order to hide to the user the boost::circular_buffer implementation since it may change in the future

What about creating an interface for the circular buffer?

[traversaro]

Opinions?

I guess eventually ideally the user should have an API in which he can pass a vector/span directly, without needing to adapt their code to have use custom types such as yarp::telemetry::Buffer<T> > . For all the internal APIs, instead, I don't think at this point is really important to clean them up until we reached the point in which we fully understand what is the user-facing APIs, and which one are the internal APIs.

[traversaro]

Fixed by #27 .