search

kennedyengineering / EE525_Final_Project

MPU6050 Kalman Filter
1 stars 0 forks source link

Updated the logger to write to a CSV file and include the timestamp a… #1

Closed luisdavidgarcia closed 1 month ago

luisdavidgarcia commented 1 month ago

Updated the logger script with two CLI arguments one for log_dir and csv_file_name (name of the log file).

Also removed the print statements of the data since it is now being outputted to a CSV file.

kennedyengineering commented 1 month ago

I like the direction this is headed.

It brings up a good question: when do you attach the timestamp? On the tx or rx side? This uses rx side, which is valid. My one concern would be if receiving stale data you wouldn't actually know when it was sampled. In other words, the assumption is that the time at which the data is received is approximately equal to the time at which it was sampled. An example of when this might not be the case is when the Arduino is connected to over serial -- it finishes its last tx, resets, and then continues to tx. On the rx side it can be difficult to differentiate the data from before and after the reset since the rx is buffered.

kennedyengineering commented 1 month ago

Sorry about the comments, the place I worked at was quite rigorous in their code reviews.

kennedyengineering commented 1 month ago

In my ideal world, I would have two tasks setup in the MCU:

  1. On MCU interrupt; read data via I2C, get MCU timestamp, and place into a queue.
  2. Main task; pop from queue, tx data over serial.

In this case testing would need to be done to see if an overflow occurs in the tx queue. If so, adjustments to sample frequency would have to be made. (Like queuing data in every other interrupt, etc.)

However it might be simpler to modify the code to include the timestamp in the collection of print statements it currently has. See https://github.com/kennedyengineering/EE525_Final_Project/blob/a8ea29e6a6ddec4aeefceb3ba539bf6ca5566b69/src/Arduino/main/main.ino#L37

kennedyengineering commented 1 month ago

From my experience in dealing with post processing data, accurate timing information is everything.

kennedyengineering commented 1 month ago

Made what I think is the easiest change. See MR #2

kennedyengineering commented 1 month ago

Since screen can work as a Linux/OSX solution, maybe we don't reinvent the wheel with this logger.py program? What if we created a src/Scripts directory and created a bash script that did the logging using screen? We could save the src/Python directory for post-processing scripts maybe...

kennedyengineering commented 1 month ago

Synthesized ideas into an issue #3