pathfinder-for-autonomous-navigation / flightsoftware Goto Github PK

Currently uplink producer/consumer only has the ability to edit integer state fields. We need to expand this ability to all kinds of state fields.

We might need to rethink (or at least think more) about docking approach angles (and also issues with magnets not pulling us together).

adcs_vec1_current_f.set(r_hat_body_arr);
adcs_vec1_desired_f.set({1,0,0});

These two lines within attitude computer ask BOTH satellites to have their +X face Zenith. Since both satellites are physically identical, it's impossible for both Satellites to be docked and have both +X faces facing Zenith.

EDIT: If the satellites are docked, the +X faces will only be 90 degrees apart from one another.

Helpful link to images with axes:

Sats:
https://cornellprod-my.sharepoint.com/:x:/r/personal/saa243_cornell_edu/_layouts/15/Doc.aspx?sourcedoc=%7B4C5A75A0-8965-42FA-8FF0-1235E81EAF10%7D&file=mass_properties_calculations.xlsx&action=default&mobileredirect=true&wdLOR=c94C53D0A-1581-4725-ADF4-FE9C63DA5CEA&cid=3f32e25a-552c-459f-97bd-c5b2991f8ded

Concerns:

Approaching with both +X facing Zenith will ensure optimal iridium comms for both satellites, but the docking faces will be 90 degrees apart. This also means the magnets will exert NO attractive pull. ISL patches will also have 90 degrees of separation.

Approaching with 90 degrees of separation will allow the dimples of the docking face to contact perfectly, and also allow magnets to pull satellites together. ISL patches will be perfectly aligned with 0 degrees of separation. But Iridium patches will be 90 degrees offset, meaning both will be suboptimal, or one will be good and the other poor.

Ideas:

• Have both satellites +X faces 45 degrees offset from one another and approach optimally for docking but not for comms
• Have both +X target Zenith, we accept that they will approach not optimally set for docking, and then do something drastic once we get close.
• Can reconsider Peck's idea of a full dipole on satellite, but that means we'd have a dipole and we could smash together without dimples aligned.
• Approach with some variable offset (state field) to dynamically adjust (or at least tune infrequently) to dynamically compromise between iridium comms and magnet/docking alignment.

LMK if I messed anything up lol

Originally posted by @shihaocao in https://github.com/pathfinder-for-autonomous-navigation/FlightSoftware/pull/120/files/ca4f9a623ba9f69455e6baa041bb9333143844c7

Mimic the detumbling "trigger count" logic in psim into Mission Manager, once the faults and current (simple) Mission Manager are merged.

#119 #126

This will require significant refactoring of the current safe hold state, which is pretty vegetative.

@shihaocao

see above

A part of ground software. See also #21

If Quake radio fails to initiate a successful SBDIX in 24 hours:

• Force the mission state to standby, wait 24 hours in that state. This puts the satellite in an comms-maximizing attitude.
• If we still don't have comms by then, power cycle the radio every 8 hours three times.
• If we still don't have comms by then, go into safe hold, which after 24 hours will reset the entire satellite.

This should probably be implemented as a separate state machine on top of the Quake manager, and should be a subset of the mission manager.

We really have more than 30% coverage, I'm sure...

• ControlTask
• Unit testing

Right now the max_config_cycles, max_wait_cycles, etc (in QuakeManager.h) have placeholder values.

In hardware tests, SBDWB, SBDRB, CONFIG do not take any longer than one control cycle.

SBDIX takes anywhere from 70 to 210 control cycles (but averages ~120).

For after Gomspace device testing is done. Subtasks:

• Mock Gomspace driver
• Output state fields of the Gomspace driver should be all the data we care about. Inputs will be bits for mission manager to control the power-cycling of non-functional devices.
• Unit testing

temp

@shihaocao Can you get a draft PR in by Sunday? There are a few things to take care of:

• Writing a mock Piksi driver that doesn't do any IO calls. Put this driver in the lib folder and call it FakePiksi; have it be a derived class from Piksi. Have the choice of driver be selected by the compiler based on a build flag. (e.g. when building for flight Teensy environments, it should select the real driver, but when building for HOOTL Teensy environments or the native platform, it should select the fake one.)

• Here are the state fields you'll need:

  • Outputs from the Piksi we care about, as well as health status fields (e.g. is_functional, number of consecutive read failures)
  • Inputs from other controllers:
    • piksi.power_cycling: The mission manager may decide to power-cycle the Piksi if it's not responding, so Piksi should be aware of this and not collect data when this flag is true.
    • quake.transceiving: When the Quake radio is doing SBDIX, the large power draw of its antenna makes GPS measurements unreliable. These measurements shouldn't be made when this flag is true.

I'll update the above inputs list if I think of more input items.

• Get some basic unit testing done that works in conjunction with the mock driver and creates the input state fields using StateFieldRegistryMock.

Instead, rely on ground data until the RTK data becomes fixed.

This is so that the GNC algorithm works correctly.

This is because, semantically, state is a part of data and is not an actuation. An uplink command should be easily discernible as an actuation.

The limited mode only uses magnetorquers.

According to meeting notes, "DCDC takes up both pins 24 and 25. Spike and Hold does not have separate pins." This needs to be addressed in software.

• Mock propulsion system driver
• ControlTask
• Unit testing

Offshoot work of #57

If we happen to frequently have comms, then QuakeManager will not stop sending, which might drain the battery.

When comms fails, we want to know about it. It would be great if we can design some statistics for comms (e.g. # of SBDIXs that have failed, # that have succeeded, the types of error codes that have been received, etc.) This is good science for the satellite.

Not an issue but a documentation note.

We want to standardize naming conventions of the many different objects that'll be floating around. Here's what I've been using so far and what I want to propose we use from this point onward:

• The _sr suffix indicates an object is a serializer
• The _f suffix indicates that an object is a StateField
• The _fp suffix indicates that an object is a shared_ptr to a StateField

We should keep updating this page as we develop more conventions. @athena255

Originally posted by @tanishqaggarwal in #126

What are the units of the magnetorquer and wheel commands in the ADCS driver?

Also, how should the exponential filters coefficients be set to ignore all history?

Issue detected by trying to run Piksi process in isolation. When Piksi device is nonfunctional, the Piksi controller attempts to power cycle the Piksi. However, the power cycler thread never runs or displays any output.

Issue mitigated by preventing power cycling if the Piksi is a fake Piksi. However, the underlying issue still needs to be addressed.

• Set +X face to radial in pointing for close approach
• Set +X outward in “point for standby” and set closest long edge to Sun

Just to note to add heartbeat_flags to a state field, and possibly future logic that changes the piksi_mode to a heartbeat_error state if there is an error.

@shihaocao

I think the Fault class should have a writeable boolean state field, say unsignal_f, that will trigger the unsignal() command, then automatically reset back to false. I'm worried about the following cases:

1. A fault flag becomes tripped.
2. On the ground, we deduce what caused it, and also realize a set of commands to upload to prevent it from occurring in the future.
3. We upload those commands, and merely ask the satellite to unsignal(), that way if somehow if it happens again, we can be notified.

Or slightly differently:

1. A fault flag becomes tripped.
2. We deduce what caused it, and realized there's nothing we can do to prevent it from being tripped again (say it'll happen every few days), but there is a set of commands to properly recover from it.
3. We upload the recovery commands, as well as the unsignal() command so that the satellite can continue to function until the fault condition occurs again (and still protect itself from the fault).

Further, in regard to num_consecutive_faults being able to still increment when a suppression or override is active, I think the release of a suppression or override should not modify num_consecutive_faults. If we do want num_consecutive_faults to be reset, merely follow the release with an unsignal_f = true.

Cases where I think this behavior is useful:

1. num_consecutive_faults == 0 for some fault initially
2. we suppress that fault because even if it is flagged we don't want it to be triggered in a critical window
3. we carry out the critical task, during which maybe the fault condition happens, or maybe it doesn't
4. when we unsuppressed, we don't follow it immediately with an unsignal(), we want the fault to immediately flag if the condition was met during the suppression period

Creating this issue to track the new integration of the new orbit controller that will eventually be coded up in PSim.

This shit is nasty

• Mock Quake driver
• ControlTask(s)
• Unit testing

This issue is a place to discuss what compiler flags relating to floating point math we want to use for flight software. Default compiler flags for the Arduino framework on PIO.

When checking if we need to enter initialization hold we should also run the error checking that we run during the "standby needed" check. Right now there are errors that could crash the satellite that don't get caught by the initialization hold check because they're contained in the "standby needed" check.

Due to power distribution issues, GPS values are not guaranteed to be usable when the radio is running.

• Take Quake SBDIX into account
• Testing Piksi dead
• Test Piksi float -> fixed RTK

A part of ground software. See also #22

Right now I am calibrating the magnetometer after eclipse, and after detumbling.

Originally posted by @nhz2 in pathfinder-for-autonomous-navigation/psim#92

This needs to get implemented into FSW.

Instead of 5 times like it currently is. Gomspace reads take a lot of time.

We/Shihao need/needs to figure out where (which control task) to create/define the Pan Epoch Internal State Field because the state field is necessary for gnc/attitude estimation calculations. The Pan Epoch Internal Statefield should be a gps_time_t.

To reduce the chances of memory wear causing mission failure, constant values in drivers should be broken out to be fully programmable. This includes things like pin #'s, I2C bus addresses. Everything should be configurable.

Note the "far in the future" tag. This is an enhancement only for post-core Flight Software development, in 2020.