 Okay. Good evening, ladies and gentlemen. At first, I need to apologize that my co-speaker, Jun Huang, is busy in something, so he cannot attend this conference. Okay. This is today's topic. We will talk about our dining space rocket flight control system. My name is George Kham. I am the Apeanics Sovereign Manager in ARC. ARC is a research organization in Taiwan, National Jiao Tong University in Taiwan. Our mission is to build the rockets from scratch. This is the flight mission about our HTTP-3A rocket. This rocket is a two-stage hybrid rocket. That means its oxide is liquid and its fuel is solid. And our mission is to need to bring this rocket to 100 kilometers high. In this slide, it shows why the rockets need the real-time control during the flight. During the flight, the rocket is under the high dynamics. That means its attitude will be changed rapidly. In order to stabilize the rockets, we need a control system to response these changes in real time. Besides, the system should be able to steer the rocket to our mission. The flight control model can be divided into three stages, sensing, computing, and actuation. In the sensing stage, there were several sensors like GPSR and IMU, which is used to gather the rockets' data. And these sensor data were delivered to the computing model, which consists of three sub-models, navigation, guidance, and control. The purpose of the computing model is to use these sensor data to generate a control command. And this control command will deliver to the next stage, actuation. In actuation stage, we will have different kinds of actulators, like TVC or BUB. And this BUB will adjust the rocket's data by executing the control command for the computing. And these changes will be detected by sensor. And so the flight control will be looped operation. And what we need to do is to make sure this flight control operation is in real time. This is the overview of our AMERIC system. Our AMERIC system consists of two sub-systems, the communication systems and the flight control system. Today, we will focus on the flight control system. First, we talk about the sensing. The sensing is the most important because it is the source of the flight control. In order to make sure this is real time performance, we put this operation in the PRU microcontroller in CPU. The PRU is designed for real time application. And it has low latency IO and isolated runtime environment. So each PRU can query the sensor individually without disturbance. For example, we can put the GPSR query in one PRU and the IMU query in another PRU. However, most of our flight control applications run on the Linux user space. So we need the communication interface between the PRU and the user space application. Currently, in order to reduce the latency between the user space app and the PRU, we use the memory map mechanism to map the PRU resource to the address space of the user's application. And then the user space application can access the resource directly. Currently, we have made two types of PRU resource. One is the data memory. It stores the query result and the INTC, which is the PRU's internal control. And we can use INTC to force synchronization between the user's app and the PRU. Then we talk about the computing models. The computing model, as I mentioned before, consists of three submodels, navigations, guidance and control. Navigation will receive the sensor data and it will do some operation. It will do some process like calibration to reduce the sensor's flaws. And co-ordination transmission to transform the co-ordinator between sensors and the rocket body. And it also consists of sensor fusion mechanism to combine different kinds of sensors to provide the currency rocket status. And these rocket status will give to the guidance model. The purpose of a guidance model is to produce the optimized steering command by the predefined mission arguments and the currency navigation data. So this is the optimized steering command will give to the control model. And the control model will reference the navigation data and the guidance data to produce the escalator command. And so the computing will put on the pre-nRT Linux systems. In pre-nRT Linux, high priority tests like our GNC or flight model can pre-enter the system almost anytime when it is triggered. So this could reduce the latency of the high priority test. Besides, high resolution timer can provide the precise time for the rocket control. And our flight control is built as the application on NASA's core flight survey. NASA CFS is an open source project. It contains OS, AALO for different kinds of platform protein. Now it supports Linux, breakers or VxWars and RS platform. And it also provides the CFE core flight circuit which consists of reliable and reusable service for development. Okay. Now we will discuss the real time issue on CFS. First, the application, the CFS application is the POSIX radar. And it is managed by the CFE executive service. So we can manage the priority of the CFS application through this ES service. And the memory model is also impact the real time performance. CFE provides the memory pool mechanism for each user to manage its own memory. The advantage of the memory pool is that the allocation is deterministic. But it is also restricted because users should pre-define its memory size. Besides, the execution time will not be constant in the multishrating environment because of the luck issue. The inter-process communication mechanism provides CFE called the software bus which is implemented by the DNS message queue. On software bus, application can publish and subscribe messages through this standard interface. So the applications can be do-sick coupled and the development individually. All of our rocket flight control applications are mounted on the software bus. And the time service is another important component. The time service in CFS has two important functions. First, it should provide the precise time for the systems. Second, you need to distribute the wakeup command. The time service has one-hertz local timer. But it also uses the external signal with high time occurrence like the PPS of GPS to calibrate the timer. Our flight control is also triggered by the time service. But the default frequency of time service is one-hertz. It is too slow for our application. So we increase the frequency for our rocket. For the actualizations, we use the E-circuit as the real-time actualization network. It is the master and step architecture with cycling operation. In this network, it could guarantee the latency and cycle time will be low in transmission. Besides, it also provides the distributed clock to synchronize all the devices on this network. So we will integrate the E-circuit master as our actualization application on CFS. E-circuit provides two types of communication, service data objects and process data objects. Service data object or called SDO is one-to-one communication, but it is not real-time. So the master will use SDO to initialize and configure the actualized driver. For the PDO, it is a cycling operation. And cycling communication, which can change the control command and the feedback for each slave node. So it is a real-time communication and is one-to-many communication. Here is an example about the control result. The XSS is the time and the YSS is the control and the feedback value. Because of the confidential issue, the value of the coordinator is heightened. So we can see the control and there is a delay between the control and the feedback. But it is not only due to the transmission delay, but also the mechanical response should be considered. And we can see the feedback, there is difference, there is a little difference between the feedback one and feedback two. That means these two devices, these two actualized devices is not synchronized. So finally, we can put all the components together and we can summarize the real-time issues. First, we need to make sure the time service should be occurrence and precise. Because you need to trigger the pilot control. And second, the communications latency of the software bus should be low. And third, we need to ensure the synchronization between PRU and CPU so that we can get the sensor data with correct timing. And finally, we should consider the GNC executing time and the EtherCAT transmission time. Before the rocket launch, we need to verify our flight control model on the ground in advance. So we build up the simulation by ourselves. The simulation model could be divided into two parts. Dynamics model and the flight model is also a GNC. Dynamics model will provide the dynamics model will simulate the flight environment and the rockets property. So the dynamics model will provide the rocket status to the GNC. And the GNC will output the control command as the feedback to the dynamics model. So the dynamics model will update the rocket status according to this control command. So the simulation will also be a loop operation. The flight control variation process includes three stages, PIL and HIL. In HIL, both the dynamics model and the GNC run in the same environment. In this stage, we could do the missions planning and the models development and the verification. And in the next stage, PIL, the GNC will be spit out and implemented as the flight survey. So in this stage, the dynamics model will generate the sensor data, not the rocket status. So in PIL, we will evaluate the flight survey performance. And the next stage in HIL, the simulator should use some instruments to simulate the rocket's physical dynamics. And the goal of HIL is to verify the total flight control system, including the hardware and the software. So the simulator will use some instruments to simulate the rocket's dynamics. And these dynamics will be detected by the sensors. And the flight control system will use these sensors data to generate the accelerator command. And the accelerator will act through this command. And the accelerator feedback will be sent to the simulator. So the simulator will update its rocket status. Our simulation, Marzo's rocket simulation is currently our simulation to verify the rocket's flight control. It is now an open source project. And it can support different kinds of rockets mission, like the KDEX ProPlus rocket and our own ARC rocket. At present, only the KDEX ProPlus rocket simulation is open. This is the result about the simulation result about the KDEX ProPlus stage. We compare the Marzo's result and the original KDEX ProPlus result. And finally, we will currently, Marzo's rocket simulation is only support SIL. And we want to port the flight model to the CFS and combine them for PIL simulation. And we also want to contribute our efforts to the CFS project, like the IO drivers and the performance improvement. Okay. Now, this is the progress of our rocket. Before 2016, we launched several SIL rockets, but it does not have the flight control. And the current project is to build the HTTP-3A rocket. So currently, we almost integrate the software and the software and verify them by the core flow test. And we plan to launch the second stage in March 2020. And the four flight tests will be arranged in August 2021. Finally, I need to thank our financial support from the Ministry of Science and Technology of Taiwan and the Advanced Rocket Research Center of National Jotong University. Thank you.