FSW Meeting Minutes - spacecraft-design-lab-2019/documentation GitHub Wiki
Active Questions
What is the intended architecture of the flight software? Infinite loop?
Could be loop-run or interrupt-run
Interrupts are technically better, but start with loops to be sure it'll work
Which sensors should be running in Low-Power mode? Which functions?
For Max: Does the PyCubed have EEPROM or something similar? In case of accidental shutdown, what options does the spacecraft have for remembering what state it's in?
It definitely has EEPROM.
Should anything be happening during the post-launch delay? Should the spacecraft be communicating with the ground station at all?
Should Data Uplink be called on every loop? Or only when an incoming signal is detected?
Let's discuss active recharge in general and the optional entrance/exit condition in particular
Definitely keep
Continue discussing later
Should we have separate attitude control functions depending on the calling state? Or is it best to have one attitude control function with different inputs? In this case, would de-tumbling and target attitude require different functions?
We gotta define the thresholds for the entrance/exit conditions
Should the thresholds have time delays to combat noise?
Discuss priority of Low-Power exit conditions
Meeting Minutes
3 October 2019
Ask Zac: What does he expect us to have by next week?
Preliminary investigation suggests:
To get it by next week takes 4 ppl @ 24/7
To get it by week 5 makes more sense
Most likely by end of quarter
Question ended up being redundant after coding rework
Thoughts on timeline?
Modified per discussion
Which states are we missing?
None ATM
Which states are extra?
Data uplink, data downlink, power dump
How far should we go in terms of perturbations?
J2 should be fine. Drag, torque, gravity gradient. For gravity, spherical term should be sufficient. Up to order 10 is reasonable for high-fidelity simulation. 4th order is more than what we need anyways. Pull in a real atmosphere and use 2.2 as your "fudge factor." We don't really care about solar radiation pressure -- just skip. Drag is, by far, the most important and most uncertain. Third-body interactions can be ignored. Maybe J4 will matter.
What's happening WRT the sensor re-work?
Still need photoresistor
Explore newer IMUs (< 2yo)
What's next?
Once we have the sim done, we want to model the sensors (i.e., inputs vs. outputs) and model the noise.
Figure out how to use the camera
10 October 2019
Converting MATLAB -> Python
Try to be done by Wednesday, 10/16/2019
“Stupid sanity checks” — make sure the MATLAB and Python functions match up
Atmospheric Model Options:
Look into MATLAB-calling-Python bridges
JB2008 is industry standard; Zac says use this one, but send him a link so we can work on making a Python wrapper for Fortran
He doesn’t care which model we use, as long as it’s representative
MSINC has a Python library, so we should probably use that one
“Unit tests”
Call MATLAB, call Python, subtract, and make sure the answer is zero
It automates the sanity checks and flags any failures
Look into doing it in STK once for a final comparison
Perturbations in order of priority, according to Zac:
J2
Atmospheric Drag
Gravity gradient
Drag torque
Solar pressure (optional)
Interface between GNC and FSW teams
Feed the GNC team fake sensor data to see if their simplified code holds up to our stress tests
They’ll be working to validate their code independently
Current sensors: magnetometer, gyro, sun sensor data
Noise models
Magnetometer & gyro have more complicated, non-white noise models
Gyro has a bias; use “Brownian” approach
Magnetometer also has a bias (not discussed further during meeting)
There are “kinks” in the coordinate axes. To compensate for this, multiply by a positive semi-definite matrix to scale all of the magnetometer measurements appropriately
Generate three random number close to 1 (Gaussian distribution; variance between 0.01 and 1)
Sample random 3D vector “that’s like a few degrees”
Turn that into a rotation matrix
The stretch is represented by I + diagm([q1; q2; q3])
Right-multiply the above sum by the rotation matrix (expm(q_hat))
Sample the axis angles and exponentiate them to construct the rotation matrix
“Axis angle” is a 3D vector whose direction is the axis of rotation and whose magnitude is the magnitude of rotation
This task is larger than we may have expected; at least a couple of weeks (probably 3 or 4, honestly)
Virtual machine
Ubuntu
Stop using windows
Camera
Get it to communicate with an SAMD51 MCU
Set a new task in KanBan
Task summary:
FSW:
Take credit for current camera task
Add to-do for communication with MCU
Get started on FSW code
Sim
Choose and implement an atmospheric model
Begin/continue modeling perturbations in order of priority
17 October 2019
Individual updates (what you worked on this week; what you should work on for next week):
Hridu/Kevin:
Aerodynamic drag implemented
J2 implemented
Zac: Don't need to calculate principal axes
Sim should be done by Monday
Fortran/MSISE atmosphere model works best on Ubuntu/Mac (not Windows)
Make sure MSISE is in the proper frame (geocentric vs. geodetic)
Zac: Verification? Use SGP4 for sanity checks. Doesn't have to be super accurate
STK class in November, we should go through
Walker:
Adafruit state machine tutorial
Began CircuitPython state machine architecture
Will continue working the state machine over the weekend
Allan:
Worked on camera, photos, SPI, communication, etc ...
Send Amazon/OpenMV lens PO to Zac
Once SD cards are in, take new BMP, PNG, and JPEG photos from 4th floor during bright lighting
Conduct JPEG trade study to determine compression level that optimizes image size w/o sacrificing too much quality
1 MB too big
20 KB too small
Find compromise
Python speed optimization
"Getter/Setter" Methods:
Don't make the state a member of the class
self.x to hold onto the state vector
Make functions to call the individual components of the state vector when they're needed
Optional; speed isn't necessary for our tasks
17 October 2019: Joint meeting with GNC
High level diagram that says what each state is, what it does and the conditions for transitioning
What we need from GNC is: in any state that says "determine attitude" and "control attitude" we need to wrap their functions
Attitude determination process constant in the background
What are the sensor measurements that will take us into each sections
How will interfaces between GNC and FSW look?
GNC consumes the current state and propagates
Interfaces should be vanilla C functions that take in scalars, e.g. 9 scalars for a 3x3 matrix
Can't use numpy on satellite
We want to do all "pass by reference" in C (pointer)
We can write our own Python matrix class
Algorithms
Sat comes out and needs sun sensors and magnetometers
For triad, need 4 vectors (2 that are unit vectors in body frame, mag sun) (2 vectors that are modeled inertial directions)
FSW gives GNC sensor data and time, GNC returns quaternion (attitude estimate)
State machine takes biases
Once Kalman filter is running, then we keep running the filter
Once detumbling is done, switch from Bdot to Andrew's control algorithms
We need to be able to get back and forth between detumbling and other states
Detumbling is effectively a reset
How will we store values in between state machine updates while traj opt is solving (parallel vs series)?
Use interrupts to do "half ass" parallel processing
Need to get a handle on maximum slew rates
In the pas cube sats have come out tumbling faster than the Nyquist sampling rate and been broken
We might want a "data dump" state while flying over ground station
Pointer/reference passing
24 October 2019
We're at the point where we should probably set up separate branches
Look into "Travis" for running test suites after pushes
PyTest recommended by Andrew as alternative
New task: Set up test suite
Learn unit testing practices
STK is November 13th (Wed of Week 8) during normal class period
As a first cut, come up with a handful of sanity checks (like drag on vs. drag off)
Then check against SGP4
Need to coordinate states with GNC team (do after today's meeting)
Consider using closed-form approximate equations to model position of Sun in ECI in sim
pip (Python horizons) to ask for Sun's position in ECI and interpolate
Need to incorporate solar flux to spoof sun sensor readings
We have 6 individual sun sensors
Spoof numbers for each sensor individually
Just dot products
Desirable to model "irradiance" from Earth and Earth glow on the night side
Hard to figure out
Most likely stochastic and noisy and not just a simple factor of the solar flux (though roughly 20%)
TODO: Implement IGRF (already on Kanban)
Kanban task already made
Special attention to coordinate frames
Takes in lat-long-alt (position)
Spits out north-east-down (rotation)
Rotate into/change to ECI
Rotate into/change to body frame
Modeling magnetometer noise:
Not quite a random walk
"Soft iron" errors
Function of electricity and metal effects in the Qube
Can't use magnetometer when torque coils are on
TODO: Get sensor models fleshed out (already on Kanban)
Gyros basically done
Look at datasheets by next week
6 sun sensors
Timeline: TBD
Desirable to get it done by next couple of weeks
State Machine:
Abstraction layer: Choose between real hardware readings and spoofed sensor readings
Added Kanban task: Define abstraction layer (see above)
Problem with serial USB communication
Use PySerial
Only one program can grab a serial port at a time
Can't use terminal and run sensor-spoofing code at the time
Figure out a way to "serialize" the numbers
Base64 would be desirable
But it doesn't work, so you basically have to convert them to strings using sprintf()
Look into ubin_ascii.Base64
Has encode() and decode()
TODO: Get state machine talking to sim to grab sensor measurements
Ensure communication in both directions
Added Kanban task
31 October 2019
MSISE module is buggy; year 2019 isn't working on Hridu's computer or Tomer's computer
Needs to be much faster
Debugging needs to be done, but problem may be inherent to MSISE
Timing issue may just be a function of which timing function we're using
Andrew's timer yielded a much faster result than Tomer's
Keep it >=10Hz
Sensors
Interpreting datasheets and getting sun models are the current priority
Involves library of sun position in ECI
Don't call JPL Horizons every simulation
Meet with Zac? He wants to look over the sensor stuff to make sure it's right
Probably meet tomorrow or Monday
Make sure to add datasheet information to the wiki documentation
Hardware-in-the-Loop Testing
System is now in the state where you press a button, the camera takes a picture and sends it to the MCU, and the MCU saves it to the SD card
Great progress; complete the mini HITL test over the next couple of weeks
STK tutorial on the 10th
Use a non-ISS TLE
7 November 2019
Software-in-the-Loop
Python wrapper should be designed as if it was CircuitPython
Wrapper includes GNC code inside
Simulation written in vanilla Python (no restrictions)
Simulation will spit out sensor measurements (gyro, magnetic field, sun vector, etc.)
Wrapper will convert this into a state and feed state to GNC algorithm
Wrapper takes GNC output and passes it to Sim (no processing necessary)
Challenge: Convert sun sensor readings to a vector the GNC algorithm can take
Andrew: Math shouldn't be that complicated. Just subtract opposite face readings and multiply by normal vector. It will be discontinuous because of the albedo effects. Our albedo models don't need to be that detailed, so it should be possible.
Just pass in the state vector in list format.
No need for state machine; just use wrapper
No MCU
Sim is revived and killed on every function call, so we need to write to and read from text file every time. Alternatively, just pass in the same data you would write to the text file to the software-in-the-loop, do nothing with it, and pass it back to the sim when it revives. Hridu prefers the latter, so we'll probably do that.
Hardware-in-the-Loop
Pretty much the same thing, with slight differences
SIM acts a black box and has understanding of quaternions and state vector
SGP4 and IGRF will be on flight computer
MCU needs to receive sensor measurements (angular velocities, magnetometer readings, sun sensor readings)
MCU needs to pass m-dot (magnetic field information) and state vector back to sim
Sim writes to text file so we can see the history if we need to
In MCU: from sim => state machine => wrapper => C++ => back to sim
What are we testing with HITL? Mainly GNC, but payload too.
Combined meeting with GNC
Recap: HITL & SITL in parallel
Massive struggle with pass-by-reference
Possible solution: build up parts of numpy (e.g., numpy array) by hand
See if there's another solution in CircuitPython that doesn't involve numpy
14 November 2019
HITL Testing
Behavior is very strange
First try hardware debugging with FTDI to see if the problem is with serial
If not, it's a software issue; need to debug code
Simulation
Fix NED to ECI rotation matrices, especially magnetic stuff
Add gyro bias to state vector
Getting gyro model fully-equipped (currently missing random walk)
Finalize sun sensor model
21 November 2019
Sun sensor
You don't get voltages—you get counts, like with PWM on microcontrollers
Next quarter
Writing GNC code for the satellite
Ideally, no more simulator stuff
Lots of hardware testing
Runtime issues
Still better than 10 Hz; just annoying for simulating and debugging
Spend next couple of weeks improving performance
Run on Stanford's FarmShare servers? Consider using flight simulator computers in Skilling
HITL
Mostly done
Might be interesting to model battery charge/discharge, solar panel currents, and current draw
Documentation
Highest priority for the next two weeks
AstroPy
May need to write our own functions to replace AstroPy
Could write data to text file and spline
Joint Meeting with GNC
Replacing pyIGRF with custom code is expected to yield massive speedup
Need mini pybind test (+1) to test pybind in CPython
Attempt a "hello world" wrapper of a C function in CPython