Present: Zilivinas Kvedaravicius, Jesper Larsen, Ernestas Kalabuckas, Mariusz. Duration: 2.5 hrs. Date: 06/08/2018

Summary of previous meeting with NTNU (Tor Arne, Evelyn and Roger)

• 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

Discussion about platform

• Integrate payload on the FM in end of Jan 2019
• 90 Wh energy capacity for our platform solution
• Safe modes on cubesat:
  • If something is off-nominal, then the (sub)system reboots
  • Treshold on power consumption, EPS controls this
  • Spin rate too high – satellite reboots to initial conditions (LEOP settings)
• Optics (we figure out ourselves)
  • Test degradation of lenses
  • Maybe test sensor in radiation events – at least learn very well how to mitigate them
  • Shielding?
  • Thermal management?
• Thermal management as of now is passive, but can be tailored to the requirements of the payload. Payload thermal management we have to figure out our selves.
• We do super-resolution ourselves – onboard? Onboard = full success criteria
• If we later want to do it onboard then it can be implemented but at our own risk
• Downlink raw data first – or else you won’t know if what you are seeing or not is correct
• We are responsible for data processing ourselves
• Testing and launch will cause things to shift (COM shifts) – they use known system identification and inertia estimation algorithms (control theory) and methods to fix this in-flight – should be less of a concern though important for ADCS functionality and HSI data products (images).
• GPS/PPS signal shall not be delayed more than the camera exposure time/readout time (clock error) per frame - for synchronization of frames when doing both Nadir and slew maneuver. Or else we get errors in geo-referencing and super-resolution plus we get motion blur that is difficult to correct.
• NA agrees that should use RGB camera for validation of hyperspectral camera imaging.
  • Also may be used for georeferencing and correction
  • Only if there is space in the c/s bus but there should be.
• If there is space then we should include SDR – but only for experimental purposes. If we want, then we can use it for robotic agent communications but should not replace S-band radio and UHF radio.
• Do a CAD model fitting of the payload – see how much space is left. According to Elizabeth’s drawings this should be fine.
• Serial or CAN bus for radio-payload communications?
• I requested them to send CAD model and drawings of the 6U platform
• Need to figure out optimal configuration for the camera placement – possibly also use the tuna cans on the platform for extra space.

Discussions about operations

• Scheduling of turning camera and other subsystems on/off
  • Timer in flight computer and power from EPS translates “this is how long the payload will stay ON and capture & store data”.
• Mission operations SW is TBD for ourselves
  • Good suggestion to use OpenMCT (TM) and SeaDas (payload data) for visual validation
• Uplink/commanding works as follows:
  • Format in CSP
  • Uses a script where scheduling of events (phases) happens
  • “Do this for X many minutes” – sequential blocks of code to run
  • Camera parameters, target location and FPGA logic updated as necessary in a script
  • Up to us which flight software we want to use. NA uses basic CSP client. If we want different software then we have to re-configure addresses to communicate between each subsystem.
• They use simple CSP also for downlink. We need to convert to our desired format.
• NA collaborates with LeafSpace
  • (UHF band in Lithuania, S-band only available in Italy)
  • LeafSpace has ground station in Kaunas
  • NA can show what us what we need
  • Fully open for us to use Lithuanian ground stations if we still want to collaborate on mission ops (but need to pay them)
  • Asked them if LeafSpace is an ok group to work with. They said yes and gave green light on using LeafSpace network. They said they are number 2 after KSAT.
  • NA says KSAT subscriptions are yearly contracts for $2000 per month. Expensive and inflexible. We would have to go for a yearly subscription. More on LeafSpace's services in other meeting minute note.

Discussions about Launcher

• Launcher we do ourselves, they can help to find the right one.
  • NA offers $200-$400 K for launcher, transport, deployer, separation mechanism.
  • They are working on launch opportunities with PSLV
• Launch price will even go further down as launch frequency increases (per company). Depends on our c/S mass how much it will cost exactly.
• Fill out launcher questionnaire and submit required documents that show environmental test requirements for FM have been fulfilled.

Discussions about ADCS and slewing maneuver

• 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 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

Other

• I should send them mission questionnaire, PPT slides, concept document, mission requirements document and mission design docs (energy budget, data budget etc.)
  • They asked for mission questionnaire since they only had the tender as reference, none of the mission design documents
• Inform each other continuously on ADCS progress, also what COTS components we want to use.
• Vytenis Buzas (CEO) worked under Marcus Murbach in MDC, NASA Ames, on a propulsion unit with TRL 4. Ames helped Lithuania on their first cubesat mission.