search

coloradocube / balloonsat

COTS balloonsat mission to test the RPi 4 with a battery UPS, a quad camarray, a GPS module, a RockBLOCK module, and a small number of Qwiic sensors
0 stars 5 forks source link

Sensorium and telemetry for the satellite #3

Open ivogeorg opened 2 years ago

ivogeorg commented 2 years ago

Description

  1. Daisy-chained Qwiic sensors:
    1. External temperature.
    2. Environmental (incl. internal temperature).
    3. 9 DOF IMU.
  2. UPS or power supply readings.
  3. GPS signals
  4. Raspberry Pi CPU temperature

Currently the data collected from the daisy-chained sensors is stored in a .csv file using this code

TO DO

  1. Adapt existing codes to collect data from sensorium listed above
    1. Create a function that will detect whether the system is moving or not, using IMU sensor. Use this function to collect the data only when the system is in motion
    2. Compose data packages to be sent by RockBlock Iridium modem #6

Knowledge

T sensor guide Environmental Sensor guide IMU sensor guide RPi internal temperature UPS power board for now Python Tutorial starting scripts upon tuning on

Deliverables

For Indoor lab test of the system:

NotfatPrince commented 2 years ago

magnetometer and/or gyroscope for sensors?

NotfatPrince commented 2 years ago

We can take a page from EyesSat book and put this I2C temp sensor directly on top of the CPU...

ivogeorg commented 2 years ago

@NotfatPrince, I am adding your good finds from Teams here:

  1. https://forums.raspberrypi.com/viewtopic.php?t=279631
  2. https://projects.raspberrypi.org/en/projects/temperature-log/0

Let's track important resources here rather than Teams. Combing through both to sync takes valuable time.

ivogeorg commented 2 years ago

An IMU might be very useful to get data about the motion of a strung balloon cubesat for planning of future flights (e.g. stabilization, etc.).

ivogeorg commented 2 years ago

The fastest solution under the current time constraints are to use the SparkFun Qwiic SHIM Kit for Raspberry Pi with extra sensors, for example the SparkFun High Precision Temperature Sensor - TMP117 (Qwiic) and others. The Qwiic devices can be easily daisy-chained on the I2C bus.

ivogeorg commented 2 years ago

Sensors and RPi HATs and SHIM connector and arriving tomorrow, Tue, Oct 26.

NotfatPrince commented 2 years ago

how to store data in excel

ivogeorg commented 2 years ago

@PaulAJanes Latest update: The telemetry gathering should be a standalone application/package. It will be controlled by the Flight Executive.

Functions

  1. Each data point has a source, polling rate, and a set of rules for normal operating range. The application polls the source and records the data.
  2. Each record has a UUID, a datetime stamp (yyyy-mm-dd hh:mm:ss, 24 hours military time format), and a set of sources in a fixed order of the data columns. Records look like a table. For example: UUID Datetime Src1 Src2 Scr3 Src4
    345-80012 2021-11-18 13:46:19 data1 data2 data3 data4
  3. Records are written to the Telemetry log as comma-delimited data. (TODO: Specify data format for each data type. Note that GPS, IMU, environmental will occupy multiple columns.)
  4. If a source or a set of sources have to be polled at a rate different from the regular periodic full-record rate for some reason, the missing columns will just be empty (commas with no characters in between).

Sources

  1. RPi task manager data: CPU usage (per core), CPU temperature, Memory usage, Storage usage, etc.
  2. (newly added) RPi registers (e.g. is it being throttled because of low battery).
  3. Discrete sensors (IMU, voltage-and-current, temperature, environmental, etc.)
  4. GPS (and built-in IMU). (See #12)
  5. UPS & other power readings (I2C). (See #23)

image

PaulAJanes commented 2 years ago

@ivogeorg I'm going to attempt to populate a lookup table with known sensor ids and associated info, such as registers, what those registers return in terms of how many bytes and what data it is, whether you can write to any registers and which ones and what can be written, what the range of return values is and what is the step value of the last LSB.

The idea is to be able to hook up any sensor to the system and have the system just figure out how to interact with it. In the inevitable event that I run out of time, I'll supplement with some specific code for known sensors.

I'll also be writing a framework for generic versions of different types so that, in the event that a given sensor is not on the table, some basic instructions exist to interact with the thing.

For now, I'm focusing on I2C interactions, but it should be easy-ish to convert for other systems.

ivogeorg commented 2 years ago

@PaulAJanes, it's probably best to use the logging facility from the Python Library. No need to reinvent the wheel. Probably the easiest way to log. We can feed into the pub-sub messaging bus before calling logging.