Implement datalogging & error handlers

Terrapin-Rocket-Team / Multi-Mission-Flight-Software

An arudino library used by the Terrapin Rocket Team as the foundation of the team's flight software.

5 stars 0 forks source link

Implement datalogging & error handlers #45

Closed varun-un closed 2 months ago

varun-un commented 4 months ago

Created the structure for datalogging, including a default Logger class, as well as specific PSRAM and Sd Card implementations. Also has an ErrorHandler singleton class that holds and logs a variable number of errors.

Check the README files for each for more information.

varun-un commented 4 months ago

Do we want circular buffer for preflight? Also, the ErrorHandler object right now depends on the Logger class, but if someone doesn't want to use that how should they do it. Do we require that all alternative logging logic extend or be a child class of Logger to maintain compatibility?

DrewBrandt commented 4 months ago

Do we want circular buffer for preflight? Also, the ErrorHandler object right now depends on the Logger class, but if someone doesn't want to use that how should they do it. Do we require that all alternative logging logic extend or be a child class of Logger to maintain compatibility?

I think a circular buffer is a good idea.

My only concern was data loss, but we should be able to trust our launch detection enough to use a circular buffer without worrying about it.

mallamacimj commented 4 months ago

Do we want circular buffer for preflight? Also, the ErrorHandler object right now depends on the Logger class, but if someone doesn't want to use that how should they do it. Do we require that all alternative logging logic extend or be a child class of Logger to maintain compatibility?

I think a circular buffer is a good idea.

My only concern was data loss, but we should be able to trust our launch detection enough to use a circular buffer without worrying about it.

Generally we want a circular buffer. In a perfect world I think it defaults to a circular buffer but when initializing the logger class, you can choose to turn off the preflight circular buffer. However, I don't know what use case that has currently so I would just go ahead with the circular buffer always preflight

mallamacimj commented 4 months ago

Going to need to need to rebase on main before merging.

varun-un commented 3 months ago

rebased and added circular buffer

varun-un commented 3 months ago

Added the changes and have 2 comments

Is the name SdCardStorage goofy?
When a file on the Sd card is created, the file suffix is passed in and the file name also includes the last file of that suffix on the card's number incremented (like 36_FligthData.csv). However, on the Logger side, it doesn't know what the file name is since the number or name is not returned, but rather a boolean of its status is. Would it be valuable to do something like have the init() call return the file name if successful, and "" if not, to help track file names, or is accessing them by the order in which they were created good enough?

mallamacimj commented 3 months ago

Added the changes and have 2 comments

Is the name SdCardStorage goofy?

When a file on the Sd card is created, the file suffix is passed in and the file name also includes the last file of that suffix on the card's number incremented (like 36_FligthData.csv). However, on the Logger side, it doesn't know what the file name is since the number or name is not returned, but rather a boolean of its status is. Would it be valuable to do something like have the init() call return the file name if successful, and "" if not, to help track file names, or is accessing them by the order in which they were created good enough?

SdCardStorage is fine lol. Accessing them in the order they are created is good enough.