¶ Pickle Rick
¶ Statemachine
¶ Diagram
¶ State description
| State | Description | Transition | Entry | update | Exit |
|---|---|---|---|---|---|
| Setup | After Setup complete | Initialises and begins serial, i2c and spi | Null | ||
| Preflight | Idle state | Command | Null | ||
| Launch | Calls Ignition of engine | Positive Acceleration Detected | Arm deployers and engine; Initialise event handler | update event handler | |
| Flight | State when rocket is flying | Apogee detected | update event handler; update apogee detection | ||
| Recovery | Chutes deployed, emit audio beacon | Reset Command | Play recovery tune | Null | |
| Debug | Debug mode; Enables Debug state transitions | Command | Set system_flag::DEBUG == 1 | Null |
¶ Commands
Remind me
¶ Flight Config
Configuration of Pickle Rick is accomplished through providing a json configuration file in the config directory in the sd card called rml.jsonc (Ricardo Markup Language). Below details the configuration options and an example configuration file can be found here (this was from Nimbus 23).
¶ General
WIP
¶ Sensors
"X_AXIS": 0,
"Y_AXIS": 1,
"Z_AXIS": 2,
"X_FLIP": 0,
"Y_FLIP": 0,
"Z_FLIP": 0¶ Networking
WIP
¶ Deployers
"id": 0, //drogue
"type": "net_actuator",
"address": 17,
"destination_service": 10¶ Engines
"id": 0,
"type": "Thanos",
"engine": {
"address": 12,
"destination_service": 10
},
"igniter": {
"address": 11,
"destination_service": 11
},
"fuelVentValve": {
"address": 7,
"destination_service": 10,
"closed_position": 0,
"open_position": 180
},
"oxVentValve": {
"address": 9,
"destination_service": 10,
"closed_position": 0,
"open_position": 180
},
"fuelPrssValve": {
"address": 7,
"destination_service": 11,
"closed_position": 0,
"open_position": 180
}¶ Controllers
WIP
¶ Events
Events perform actions on deployers, engines or controllers when they are triggered if their condition is satisfied. Each event definition must have an id, which represents its position in the json array and has an optional parameter to add a human readable name (recommend when analysing flight data). Single fire determines wether an event can be triggered multiple times or not. Cooldown allows users to specify a required cooldown period before an action is performed again if the event is not single fire. The action array allows multiple actions to be performed, each with their own parameter. The parameter is contextual to whatever action type is selected, so for instance in the case of a pyro, the parameter will specify the pyro on time. Conditions are stored as a binary decision tree where each leaf node will represent conditions to be checked while their ancestors will be logical binary operations up to the root node. Certain condition patterns can be employed to achieve specific logical results, some examples are given below.
¶ Simple comparison
This example shows a simple comparisons of conditions. Conditions can be nested, however there is a maximum recursion depth.
"Events":[
"id": 0,
"name" : "main parachute", // this is an optional parameter
"single_fire": true,
"cooldown": 0,
"action": [
{
"type": "deployment",
"id": 1,
"param": 10000
}
],
"condition": {
"operator": "AND",
"condition": [
{
"operator": "MORETHAN",
"flightVar": "Position",
"component": 2,
"threshold": -500 //500m AGL in NED
},
{
"operator": "MORETHAN",
"flightVar": "TimeSinceApogee",
"threshold": 0
}
]
}
]¶ Time based threshold
In this example we want to trigger the event if the vehicle is acceleration upwards with more than 1g for more than 2 seconds. This can be achieved by creating a dummy event every time down acceleration is greater than -1g, and triggering our main deployment event if the time since our dummy event is greater than the timeout of 2 seconds.
"Events":[
"id": 0,
"single_fire": false,
"cooldown": 50, // realistic sampling?
"action": [
],
"condition": {
"operator": "MORETHAN",
"flightVar": "Acceleration",
"component": 2,
"threshold": -9.81 // 1g of upward acceleration
},
"id": 1,
"single_fire": true,
"cooldown": 0,
"action": [
{
"type": "deployment",
"id": 1,
"param": 10000
}
],
"condition": {
"operator": "MORETHAN",
"flightVar": "TimeSinceEvent",
"component":0, // aD > -1g
"threshold": 2000
}
]¶ Estimators
The pickle rick flight software consists of an orientation estimator and a position estimator. To handle sensor error events, these estimators are managed in a state machine as detailed below.
¶ Orientation
Orientation estimation is accomplished using a madgwick filter fusing the output of the ICM20608-G accelerometer and gyroscope as well as the MMC5983MA magnetometer. The implementation has been taken from the arduino library, with slight modifications to support a NED coordinate frame and support for Eigen vectors. While the madgwick filter is a computationally efficient orientation filter, it suffers from a key flaw, which is that the accelerometer is used to detect a gravity vector to determine the down direction, and compensate for gyro drift. While on drones this is fine, rockets have a sustained high acceleration vector from the thrusting of the engine. This force vector is not necessarily aligned with the gravity vector and hence the estimated orientation will be wrong. For short enough burns this can likely be mitigated by increasing the gyro bias however this has not be quantified.
¶ Localisation
The localisation filter is an extended Kaman filter with the following state.
¶ Apogee Detection
To detect apogee, an algorithm based around successive quadratic polynomial fitting is used on altitude data from the flight controller Kalman estimator, sampled at 50Hz, across a shifting window of 100 data points. The subsequent time series is summed and the resulting system is solved using householder QR decomposition. The following quadratic fit coefficients allow for a complete characterization of the vehicle’s trajectory under an arbitrary constant acceleration. As the vehicle approaches apogee, the vertical acceleration of the vehicle tends towards gravitational acceleration, and hence the quadratic fit to the vehicle trajectory will converge. The maxima of the altitude-time quadratic fit as well as the time when the rocket should reach this maxima can easily be calculated analytically from the quadratic coefficients. Finally, by simply comparing whether the current time is greater than the predicted apogee time, as well as verifying the current altitude is lower than the apogee, apogee can be detected in a computationally efficient, and noise-resilient way. To further improve the algorithm’s robustness, a minimum altitude of 100m is required for the algorithm to be able to trigger as well as a Mach lockout, which prevents apogee prematurely being detected due to compression shocks forming on the rocket above transonic speeds.
Below are example apogee detection sequences that were calculated by pickle rick v2 during the test flight campaign at MRC on 14/04/24. The dotted red lines show the successive quadratics being fitted to the altitude data from the estimator. The highlighted red region shows the area where the vertical velocity is below the mach lockout limit, and the green line shows detection. (These graphs make me happy ngl)
Autogenerated on 2022-06-10 using 1337 h4xx0r 5k111z, from ye olde Confluence Wiki
Old Metadata: Created by de Silva, Kiran, last modified on Mar 12, 2021
ID: 250299791