Versions Compared

Old Version 1

changes.mady.by.user Unknown User (santora)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (livermor)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • FlatSat will be accessed remotely (can start this asap in Fall)
  • FlatSat uses CSP client, every subsystem has CSP address (access thru ethernet)
  • Payload controller fully accessible with reconfiguration of processing chain, data levels and command & control
  • Full subsystem capability (baseline)
    • ADCS
      • Magnetometers
      • IMUs
      • 5x sun-sensors
      • Star-tracker
      • Reaction wheels
      • Magnetorquers
    • Solar Panels
    • EPS
    • Flight Computer
    • Payload controller
    • S-band radio
    • UHF radio
  • Use Flatsat subsystems on our own premise at some point, install dummy masses to simulate the satellite (for example for ADCS testing) – dummy-EM
  • May test the imaging of HSI remotely through TCP/IP or Ethernet
    • I.e. test image capturing and storage à remote à transmit the downlink capability à then validate the images back at NTNU
    • UHF capability also to be tested – downlink TM, uplink TT&C
  • We don’t buy a standard engineering model (flatsat instead as well as flight model)
    • Integration of payload will happen under supervision of NA technical representatives
    • Transport the FM to Trondheim, will be sent to launcher from Trondheim
    • Only minimum environmental testing necessary: shake & bake (vibrations)
      • Radiation test is not necessary
    • Certainly may delay the timeline and introduce unknown costs
    • If FM breaks or something goes wrong, consider it as an expensive EM
    • How to test the ADCS? In Helmholtz coils, sun-sensor with FM?
      • We verification and validation of our/NA’s controller algorithm
    • Shall use FFI, NTNU facilities etc. for environmental tests
    • Use clean room at NTNU for integration

...

  • 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) 
      I will
      • 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).

    ...