Agile ACMS Software Fast Prototyping for Real-time Validation with Hardware in the Loop

Transcription

1 Agile ACMS Software Fast Prototyping for Real-time Validation with Hardware in the Loop Denis Fertin European Space Technology Centre (ESTEC), European Space Agency, Noordwijk, The Netherlands Abstract The Spectra mission, one of ESA candidate Earth Explorer core mission, aims to determine the bi-directional reflectance function (BRDF) of representative terrestrial biomes in order to model the carbon cycle at a global level on Earth. The measurement of the BRDF function needs several images of the same scene taken with different viewing angles. Rather than slewing the instrument line-of-sight, the mission relies on slewing the whole spacecraft with a cluster of four control momentum gyroscopes (CMG): an innovative agile Attitude Control and Measurement System concept with stringent manoeuvrability and stability requirements. To secure the development of this innovative ACMS, ESA has launched two parallel technological activities targeting real-time validation in closed-loop of the prototype software of a control momentum gyros based ACMS with a representative CMG breadboard. The objectives of the activities were to prototype and test the ACMS in real-time on a flight microprocessor with minimum development time and cost. To reach these objectives, the maximum use of innovative auto-coding techniques was required for the prototyping of the ACMS software as well as the development of the real-time simulator. After a presentation of the mission and ACMS concept, the methodology used for the prototyping and the outcomes achieved will be highlighted. Introduction Control momentum gyroscopes are necessary technologies for a new class of Earth observation mission featuring high attitude manoeuvrability and high pointing accuracy. Among this new class of missions, Spectra, is one of ESA earth explorer candidate currently in phase A. This paper will present the Spectra ACMS requirements and the activities performed to prototype the ACMS software in a cost efficient way. To validate the ACMS concept, the final objectives were to run the prototype S/W on a representative ERC32 space microprocessor within a real-time test bench first with simulated equipments and then with a breadboard of the CMG.

2 Project context: the Spectra mission The Spectra mission objectives are to describe, understand and model the role of terrestrial vegetation in the global carbon cycle and its response to climate variability under the increasing pressure of human activity [1]. To reach these objectives the raw observation products will be seven images of the same scene taken with various viewing angles in order to decouple the surface and atmospheric impact on radiometric measurements. The specified imaging agility needs are up to 30 deg of depointing with respect to Nadir in the across track direction and up to 60 deg in the along track direction. Agility is needed for the rallying manoeuvres between two different attitude needed for two different viewing angles and during the imaging phase for the yaw steering required to compensate for the image geometric deformation due to Earth s rotation. A motion compensation is used during an acquisition in order to increase the available observation time for one scene. 3 rd slew 4 th slew Orbit Acq. 3 Image acq. with slow-down factor of 2 Acq 4 Acq. Acq 5 Along track agility Target (50 km) Earth S/C velocity vector Across track agility Towards Earth centre OZA=39.36 Roll=35 Target Figure 1: Illustration of across and along track S/C manoeuvring requirements during image acquisition To meet these agility requirements, two solutions can be envisaged: orient the instrument line-of-sight with a mechanism or slew the entire S/C. Trade-offs have been performed taking into account project risks, cost and technical feasibility issues: the present proposed baseline is based on an agile spacecraft relying on a cluster of four single axis Control Momentum Gyros to meet the high torque needed to slew a spacecraft of the one ton class. To provide the widest isotropic torque domain, the optimal layout of the 4 CMGs consists in orienting the gimbals axis along the normal of the faces of a pyramid. With such a configuration, the over determined non-linear and time dependent relation between gimbals angles and produced torques presents singularities [2]. In the past few years in Europe, much work has been dedicated to prove the feasibility of a CMG based ACMS: emphasis was put on the actuator hardware prototyping, [3] and [4), and on the ACMS functional studies, [2], [5] and [7], but

3 the feasibility of the complete control system has up to now, only been demonstrated by analysis and simulations. In order to secure the Spectra spacecraft development, ESA initiated the development of a CMG breadboard and a prototype ACMS software running on a representative ERC32 space microprocessor. These developments were to demonstrate the feasibility of the CMG based ACMS via closed-loop real-time test including the CMG breadboard. Due to the high interest to investigate alternative approaches, two companies were selected to work in parallel: Alcatel and EADS Astrium. ACMS architecture and modes Figure 2: CMG breadboard mock-up The proposed solutions for the Spectra bus consist in an adaptation of existing buses: Pleiades spacecraft for EADS Astrium, Proteus for Alcatel. Both solutions rely on the same type of sensors and actuators on board: Magnetometers, Sun sensor(s), Star tracker, Gyroscopes, Magneto-torquers, And a cluster of four EADS Astrium/Teldix CMGs [3]. Apart from the imaging mode based on CMG control, the main difference between the proposed Spectra Bus concept and classical wheels-based ACMS for earth observation is the deletion of the attitude thrusters control mode during orbit manoeuvre. The high torque capacity of the CMG cluster enables the control of the high disturbances generated by orbit control thrusts. Therefore, the ACMS feature essentially two modes: The acquisition and safe mode, The normal mode used for rallying manoeuvres, imaging and orbit control phases.

4 Acquisition and Safe mode Both buses rely on magnetic control for the acquisition and safe mode. The Alcatel concept relies on magnetometer and sun sensors measurements for attitude and attitude rates estimation, while attitude control is performed with magneto-torquers and the CMGs to provide an internal kinetic momentum for gyroscopic stiffness. The mode is sequenced in three phases: The Rate damping phase aims at controlling the body angular rates, The Sun pointing phase creates an internal angular kinetic momentum with two CMG wheels and orient the total angular kinetic momentum towards the sun, The Barbecue phase adds a body angular momentum to stabilise the spacecraft and relax thermal constraints. The Bspin law EADS Astrium patented concept relies on 3 magnetometers and one large field-of-view sun sensor for measurements and magneto-torquers for actuation. The control law simultaneously controls the variation of the magnetic field direction in the S/C frame to create a body kinetic angular momentum and reorient it towards the sun direction. The Alcatel concept is applicable to all inertia configurations whereas the EADS Astrium control law is constrained to spacecraft configuration with inertia along the solar array normal close within 20% to the minimum or maximum inertia. The advantage of the EADS Astrium s Bspin law is that such a solution uses simple, flight proven sensors and actuators different from the one used in normal mode. Normal mode The attitude estimation function relies on a classical gyro-stellar estimator implemented with quaternion formulation to cope with large angle manoeuvre constraints. The estimator is a constant gains filter that may be tuned not only to optimise the performance but also the convergence time since it is necessary to reach steady-state performance in the limited time between rallying manoeuvre and imaging phase. The controller is a simple Proportional Derivative (PD).

5 Attitude Guidance law REF q SC / ECI REF ( ω ) SC / ECI SC REF ( ) SC ECI SC & / ω On ground Torque Estimator qˆ ( ) SC / ECI feed-forward ω SC ECI ) / SC Controller CMG feed-forward control Moore-Penrose On board STR & gyros T CMD CMG Spacecraft Dynamics & environment Figure 3: CMG based normal mode control loop (CMG magnetic off-loading used to avoid saturation of the CMG cluster by disturbances is not shown) The normal mode control relies on a feed-forward term for the singularity avoidance function, [7] and [2]. The robustness of the singularity avoidance law is essentially demonstrated through Monte-Carlo simulation since the CMG steering laws are non-linear time dependent relations. To enable smooth transition between two attitudes separated by a large angle, as for example from safe mode to normal mode Earth pointing attitude, the fine PD controller is changed for a rate bias only controller as soon as the attitude error exceeds a given threshold. In both designs, a low bandwidth magnetic controller is used to avoid a drift of the CMG cluster kinetic angular momentum due to disturbance torques. This magnetic off-loading is similar to classical wheel off-loading magnetic controller used on low Earth orbiting spacecraft. Real-time test bench design The one and only objective of the test bench is to enable closed-loop test of the ACMS prototype software running on an ERC32 space microprocessor with the CMG breadboard to demonstrate the feasibility of the complete system and evaluate available margins of CPU and memory. Real-time test bench requirements The only requirements imposed on the real-time test bench were: To include the prototype ACMS S/W running on an ERC 32, To include the CMG breadboard developed in a separate contract.

6 DS 4003 DS2201 I/O DS1005 To include a device to represent the gyroscopic disturbances torques applied on the CMGs because of the spacecraft motion. The CMG breadboard development was mainly focused on mechanical issues, as a consequence the CMG electronics is implemented using the dspace fast prototyping system. Therefore, some dspace boards and CMG wheel electronic ground support equipment (GSE) have to be included in the test bench. Real-time test bench design choices The main design choice facing both contractors was to choose the real-time system to represent the spacecraft and remaining CMG cluster dynamics, kinematics and environment and to define the hardware interfaces: Alcatel decided to build the real-time test bench around Eurosim. EADS Astrium decided to build the real-time test bench using the dspace system. Synoptic of the complete test benches are shown on Figure 4 and 5. EUROSIM CMG Breadboard DKE DKE Files.c RS422 CMG H/W Matlab Simulink RTW I/F I/F driver.c GPIB Rotation table TM/TC Scramnet I/F RS422/RS432 RS232 IP AOCS.c OBASW Data Data ERC32 Handling.a ObjectAda RAVEN Figure 4: Alcatel real-time test bench synoptic The main differences in the test bench design are: In the EADS Astrium concept built around dspace, the interface between Dynamics Kinematics and Environment (DKE) module and the CMG electronics are dspace internal interfaces. In the Alcatel test bench the 3-axis rotation table is commanded in closedloop to induce the actual gyroscopic torques applied by the S/C on the CMG whereas in EADS Astrium design the 3-axis rotation table will be commanded in open loop only to characterise the behaviour of the CMG with known gyroscopic torques. EADS Astrium design includes a 1553 bus representative of actual flight hardware whereas Alcatel s scramnet interface is not used in space avionics.

7 The TM/TC is sent and retrieved by a simple PC executable in the Alcatel solution whereas in the EADS Astrium solution the simulink / Real Time Workshop (RTW) external mode is used. In both solutions, the simulation software of the Dynamics, Kinematics and Environment module are derived from the functional engineering simulator simulink models using auto coding with RTW. Finally, the only specific developments performed for the real-time simulator are: customization of interfaces drivers and synchronisation protocol. Matlab Simulink RTW DKE DS 1005 Files.c + CMG ctrl ctrl I/F I/F driver.c driver.c DS 1005 DS I/O CMG Breadboard DS 4003 DS2201 I/O CMG H/W Rotation table TM/TC 1553 Open-loop cmd Simulink External mode NetROM IP ACMS.c OBASW ERC32 VxWorks Data Data Handling.c Handling.c Figure 5: EADS Astrium real-time test bench synoptic Prototype S/W development and functional simulator design The only objective of the functional simulator is to be used as the starting point for the prototype On-Board Attitude Software. Therefore, the functional simulator has not been optimised for extensive performance or robustness tests but to enable autocoding of the simulink models. Functional simulator design Classically ACMS simulator used for control engineering represents only one mode, but the functional engineering simulator used to generate the prototype software must include all ACMS modes, mode manager and a TM/TC interface to be fully representative of a simplified flight software. The simulator becomes much more complex and a lot less practical for performance and robustness analysis. Nevertheless it remains much more simple than a real flight S/W including equipment management function and failure detection isolation and reconfiguration logic.

8 Prototype S/W development Three different methods have been applied to generate the prototype On-Board Attitude Software. EADS Astrium attempted to use ObjectGeode a SDL development tool, this method was successful but relatively heavy given the simplicity of the real-time architecture. Finally they relied fully on RTW to generate the complete software. On the contrary, Alcatel used RTW only for the Attitude Control Measurement System and developed the data handling part with hand coding. To facilitate the auto-coding process, the functional engineering simulator clearly separates: The TM/TC interfaces of the ACMS, The mode manager function, The synchronous ACMS algorithms, The asynchronous ACMS algorithms, The bus acquisitions and commands, The Dynamics, Kinematics and Environment. Figure 6: EADS Astrium functional engineering simulator The asynchronous algorithm may not be simulink model but s-functions encapsulating C-code. When relying fully on RTW to generate the prototype software, the simulink diagram of Figure 6 is auto-coded without the Dynamics, Kinematics and Environment module and replacing the bus acquisitions and bus commands module by s-function interfacing with the required I/O driver. When using RTW to generate the ACMS part of the S/W, only parts corresponding to the mode manager and the ACMS algorithms are auto-coded.

9 Results Both companies managed to develop the prototype software and run a real-time closed-loop test with the OBASW running on the ERC32 and a simulated CMG cluster in less than 20 months. The results of the real-time closed loop reference run on the ERC32 matched directly the corresponding results obtained with the functional engineering simulator taking into account the processor arithmetic differences and the expected real-time delays. Figure 7 below shows performances during a typical BRDF sequence, these performances were obtained on the EADS Astrium functional engineering simulator and reproduced with the real time test bench with simulated CMGs. Figure 7: CMG gimbals angles and angular rates during a complete BRDF sequence (first row), Spacecraft angular rates and angles control error during a complete BRDF (second row) and zoom on an imaging phase (third row). Real-time closed-loop tests with the CMG breadboard will be performed at the end of Conclusion The fast software prototyping approach applied has highlighted the main advantage of auto-coding tools. In particular, the ability to keep alive the attitude control and measurement system functionalities facilitates the S/W development steps: software

10 validation efforts are reduced to non-regression tests and development time and cost are effectively decreased. Autocoding has also simplified the design of the real-time test bench Dynamics, Kinematics and Environment module, nevertheless, some work remains to adapt interface drivers and take into account synchronisation constraints specific to each project. One must not underestimate the increased complexity of the simulink functional engineering simulator. It must be tailored to include all the functionalities of the Attitude Control And Measurement System and not only the algorithms to be tested in real-time. Acknowledgement The projects have been performed under the lead of M. C. Rabéjac at EADS Astrium and E. Montfort at Alcatel Space. The respective project success is entirely due to their commitment to it. References [1] SPECTRA Surface Processes and Ecosystem Changes Through Response Analysis, Reports for mission selection, ESA-SP-1279(2), April 2004 ( [2] A. Defendini, K. Lagadec, P.Guay, T. Blais, G. Griseri, Low cost CMGbased AOCS design, Proceedings. of the 4th ESA International Conference on Spacecraft Guidance, Navigation and Control Systems, Oct [3] A. Defendini, P. Faucheux, P. Guay, J. Morand and H. Heimel, A compact CMG product for agile satellites, Proceedings of the 5 th ESA international Conference on Spacecraft Guidance, Navigation and Control Systems. [4] G. Carron de la Morinais, C. Salenc, M. Privat, Mini CMG development for future European agile satellite, Proceedings of the 5 th ESA international Conference on Spacecraft Guidance, Navigation and Control Systems. [5] Bénédicte Girouart, Isabelle Sebbag, Jean-Michel Lachiver, Performance of the Pleiades-HR Agile Attitude Control System, Proc. of the 5 th ESA international Conference on Spacecraft Guidance, Navigation and Control Systems. [6] X. Roser, P. Silvestrin, J.Y. Labandibar, F. Jubineau, Agile AOCS definition for an optical Earth Observation mission: LSPIM, Proceedings of the 4 th ESA international Conference on Spacecraft Guidance, Navigation and Control Systems. [7] C. Salenc, X. Roser, AOCS for agile scientific spacecraft with mini-cmg s, Proceedings of the 4 th ESA international Conference on Spacecraft Guidance, Navigation and Control Systems.