Mainboard issueshttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues2021-04-24T20:18:47Zhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/12Update Finite State Machine2021-04-24T20:18:47ZahanssonUpdate Finite State Machine**Update FSM according to the picture attached below**
The structure of the FSM should look something like this:
Start-up --> Armed --> Drogue Descent --> Guided Descent
**Armed:**
1min before the drop, the height deployment is activ...**Update FSM according to the picture attached below**
The structure of the FSM should look something like this:
Start-up --> Armed --> Drogue Descent --> Guided Descent
**Armed:**
1min before the drop, the height deployment is activated (assuming the barometer returns correct pressure/height)
_**Transistion Armed --> Drogue Descent:**_
Via LoRa: Pilots start counting down from 10. At 5 a pre-timer is initialised. After the pre-timer has count down to zero it initalises the transistion to the drogue descent where the safety-timer is started simultaneously.
**Drogue Descent:**
Both deplyoment methods are active: Height and Safety timer trigger
**Important:**
- If LoRa fails to initialise a state change from Armed to Drogue descent, it should still be possible to reach the state Guided Descent via Height detection. (Skip state Drogue descent).
- On the picture in the bottom right is a schematic logic of the FSM.
![IMG_20210326_170932](/uploads/9e0d4df8dcab6728bbe2d19d303868a5/IMG_20210326_170932.jpg)First Drop TestLukas VogelLukas Vogel2021-04-07https://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/11Sensor drivers are missing checks for faulty sensors2021-06-28T12:38:53ZLukas VogelSensor drivers are missing checks for faulty sensorsThe sensor drivers don't check the value of the reading yet and whether it makes sense.
This can best be implemented directly in the driver, rejecting faulty measurements and reporting a sampling error.The sensor drivers don't check the value of the reading yet and whether it makes sense.
This can best be implemented directly in the driver, rejecting faulty measurements and reporting a sampling error.First Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/10Feature: Hardware self-checks2021-06-28T12:38:22ZLukas VogelFeature: Hardware self-checksThe hardware needs to be able to check its integrity prior to helicopter attachment.
- [ ] Self-check of I2C connections
- [ ] Self-check of SD connection
- [ ] Plausibility check of sensor values
- [ ] Self-check of LoRa connection
Fu...The hardware needs to be able to check its integrity prior to helicopter attachment.
- [ ] Self-check of I2C connections
- [ ] Self-check of SD connection
- [ ] Plausibility check of sensor values
- [ ] Self-check of LoRa connection
Furthermore, we want a continuous connection to our LoRa "ground station"
- [ ] Implement regular status reportingFirst Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/9Feature: Disarming2021-06-28T12:39:09ZLukas VogelFeature: DisarmingCurrently, the system does not correctly handle disarming.
- [ ] Add transition from the "armed" and "guided descent" states to the "disarmed" state (only triggered by user via LoRA)
- [ ] Implement the transition: Stop the safety timer...Currently, the system does not correctly handle disarming.
- [ ] Add transition from the "armed" and "guided descent" states to the "disarmed" state (only triggered by user via LoRA)
- [ ] Implement the transition: Stop the safety timer and the height detection
- [ ] Report correct disarming to user
- [ ] Decide whether re-arming should be possibleFirst Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/8Feature: Safety timer2021-04-03T14:38:58ZLukas VogelFeature: Safety timerThe safety timer that gets started upon dropping the system needs to be implemented.The safety timer that gets started upon dropping the system needs to be implemented.First Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/7Improvement: Rework SPI communication with receiver board2021-06-28T12:40:00ZLukas VogelImprovement: Rework SPI communication with receiver boardRight now, the SPI communication is primarily suited for transmitting from the receiver board to the main board. It also lacks support for variable-length messages.
- [ ] Implement a variable length SPI protocol
- [ ] Improve mainboard ...Right now, the SPI communication is primarily suited for transmitting from the receiver board to the main board. It also lacks support for variable-length messages.
- [ ] Implement a variable length SPI protocol
- [ ] Improve mainboard to receiver board transmission: Add transmission queue on STM32F4-side
- [x] Fix issue where only the first few bytes are received correctlyFirst Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/6Feature: Implement mainboard sensors2021-04-19T13:07:29ZLukas VogelFeature: Implement mainboard sensorsBecause we did find enough pins in the end, we can also directly connect two BNO-055 and two BMP-388 to the mainboard microcontroller, allowing for more reliable sensor sampling.
- [x] Add BNO-055 and BMP-388 drivers to repository
- [x]...Because we did find enough pins in the end, we can also directly connect two BNO-055 and two BMP-388 to the mainboard microcontroller, allowing for more reliable sensor sampling.
- [x] Add BNO-055 and BMP-388 drivers to repository
- [x] (Re-)Implement sensor task setup
- [x] Implement correct calibration of the BNO-055
- [x] Rewrite the BNO-055 vendor library to allow for multi-device support
- [x] Make sensor sampling support rates up to 100Hz
- [x] Implement sensor redundancy and mean calculation
- [x] Connect sampled sensor data to the state estimation input
- [x] Sync sensor sampling with the state estimation so that the data should always arrive before the deadline.First Drop TestLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/5Feature: Multi-file support on SD card2021-06-28T12:39:14ZLukas VogelFeature: Multi-file support on SD cardIt would be nice to have multi-file support on the SD card, e.g. the logging framework automatically sorts the different types of log entries into different files.
With the current architecture of a stream buffer, this proves complicate...It would be nice to have multi-file support on the SD card, e.g. the logging framework automatically sorts the different types of log entries into different files.
With the current architecture of a stream buffer, this proves complicated, because one would need multiple stream buffers that need to be regularly checked.Lukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/4Feature: Add remote deployment via LoRa2021-06-28T12:39:20ZLukas VogelFeature: Add remote deployment via LoRaBecause we can't touch the system during the parachute deployment, it needs to be capable of triggering the deployment remotely.
- [x] Add LoRa code to the repository
- [ ] Connect LoRa packet reception to FSM inputs
- [ ] Test correct ...Because we can't touch the system during the parachute deployment, it needs to be capable of triggering the deployment remotely.
- [x] Add LoRa code to the repository
- [ ] Connect LoRa packet reception to FSM inputs
- [ ] Test correct FSM transitioning with LoRaParachute Deployment Testhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/3Feature: Implement servo steering2021-04-27T20:45:40ZLukas VogelFeature: Implement servo steeringTo be able to deploy the parachute, the deployment servos need to be actuated. The following tasks have to be fulfilled until this feature is fully implemented:
- [x] Write HAL function for the servos and include in FSM transition
- [x]...To be able to deploy the parachute, the deployment servos need to be actuated. The following tasks have to be fulfilled until this feature is fully implemented:
- [x] Write HAL function for the servos and include in FSM transition
- [x] Add the code for the real servo to the repository.Parachute Deployment Testhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/2Model missing in HAL2021-06-28T12:40:20ZLukas VogelModel missing in HALThere is no model implemented in the current HAL. The HAL just makes up some sensor data.
- [x] Add complete generation of sensor data (also GPS and so on).
- [x] Replace fake sensor data with the model's state.
- [ ] Add noise onto the...There is no model implemented in the current HAL. The HAL just makes up some sensor data.
- [x] Add complete generation of sensor data (also GPS and so on).
- [x] Replace fake sensor data with the model's state.
- [ ] Add noise onto the sensor data obtained from the model.Hardware Abstraction Layer CompletedLukas VogelLukas Vogelhttps://gitlab.ethz.ch/phoenix/aris-phoenix-mainboard/-/issues/1Can't simulate SD without hardware2021-04-28T14:26:13ZLukas VogelCan't simulate SD without hardwareNeed to implement the hardware abstraction layer for the SD card.
Instead of logging to the SD card, just write to UART via DMA.Need to implement the hardware abstraction layer for the SD card.
Instead of logging to the SD card, just write to UART via DMA.Hardware Abstraction Layer CompletedLukas VogelLukas Vogel