...
- They agree very well on how I/we should tackle the problem, our proposed solution is pretty well aligned.
- The reaction wheel design and systems sizing I did made sense to them. Though they will probably go with their standard RW.
- No/limited access to source codes of ADCS, develop yourselves, may look but not touch in-flight or pre-flight etc.
- IP restrictions
- Careful of not stealing or distributing code
- Can work on hardware testing together (in same manner as I will could do at G-NAT, NASA Ames)
- Test with sensor data (raw), feed into kalman filter/sensor fusion, then feed into a self-developed controller and see response with dummy masses
- They don’t have immediate answer on which controller suits the mission & slew maneuver best
- They use LQR and sliding mode controller right now
- For our application they would build a new controller algorithm => collaboration with me, they would like to investigate new controllers and compare
- Needs to be tested, Hardware-in-the-loop, simulations
- NA is open to guide, give feedback, validate and test the controllers
- Jesper was very open to publish material about this – do not worry about IP from NA. They are implementing it. Credit them if it is reasonable. Since he is from academia, he understands NTNU's perspective and convinced NA that it is ok to publish stuff even through they execute the algorithm on their c/s bus.
- Theory, modelling, simulations should be published asap. Results from application/mission should also be publishable but not in detail how NA implements the controller and executes it on this hyperspectral imaging mission – NA worries about IP – not sure how to tackle it. I mean: it depends how the paper is written plus the script/code will not be published so it does not matter? Jesper agreed with me.
- I shall ASAP develop modelling and simulation tool for 6U S/C rigid body doing slew maneuver – they will give feedback on a regular basis.
- Development of "my" new controller should be done in parallel to their own – though I will also give guidance and inputs to them regarding the mission requirements
- My controller should be a side-thing to be tested in addition to their algorithm – pick which is best for the mission. Ideally I would like that we work fully on it together.
- Jesper is happy to act as an advisor on this matter (he has very good practical knowledge about ADCS on cubesats)
- May explore time optimal controller with nonlinear programming and MPC, as well as unscented kalman filter (Jesper has published about the latter for c/s application)
- Use the IMU only during slew maneuver (a different computing block on this for ADCS that is different than pointing and attitude estimation) – we take in less random noise from other sensors.
- Other sensors are still turned ON but their data are not going into the slewing controller algorithm since our reference is only slew rate – not the viewing angle and ground point.
- Synchronization important, attitude and viewing angle, sun zenith and orbit knowledge need to be timestamped at same frequency as the camera’s FPS à -> each pixel has accompanied data for fusion later. With star-tracker the attitude knowledge should be very precise.
- Jesper: ADCS runs nominally at 4 Hz, so there could be lag in attitude+orbit data but there will be a constant offset which can be shifted to each pixel.We shall do in-flight calibration on the ADCS subsystems from pass to passUse star-tracker for attitude knowledge – very precise with current state-of-the-art COTS
- Enough with 1 star-tracker, not 2. 2 Startrackers give 1 sigma higher (up to 2 sigma) such that attitude knowledge has higher certainty, but costs a lot hence not worth it. They are are also skeptical of 0.01 deg accuracy (2 sigma).
- Blue Canyon Technologies claims 0.002 deg (1 sigma) by only using 2x star-trackers!
- NA doesn’t believe in BCT’s accuracy claim
...