The whole PHM (Prognosis and Health Management) system for the avionic EMA (Electro-Magnetic Actuator) works steadily. I've been working day and night on this project for the past three months! No time for play indeed. But now the simulink data matches perfectly with the actuator data and the particle filter algorithm works! Next mission is to finish my master's degree thesis and wait, just wait...
Take a glance of the sensor signal acquisition board (Click it to see the full image). You may see the EMA on the topleft, and the acclerometer sensor (it's on the left of the picture, in the middle). Acclerometer sensor is temporarily not functional so I have to detach it from the actuator.
Below is the fault diagnosis and prognosis result (The turn-to-turn winding fault is detected and the actuator's remaining useful life--RUL is calculated and shown).
There is still a slight problem: I calculated the PDFs (Probability Density Function) according to the particles in PF algorithm, and tried to show them in a TeeChart Winform control. However, the result seemed not good at all. Former PDFs are partially shadowed by newer PDFs. There must be a better way of showing them with something else.
The simulator node is an important part of our lab's distributed simulation system. Three infrared radiation sources of the airplane are considered in the simulation: fuselage, hot spot and plume.
This simulator runs on my android phone (600MHz CPU), Radiation value are calculated on several discrete points according to Planc's law for black body radiations, and the final results are calculated via cardinal interpolations. I also added a trackball function: You can touch and slide the screen to rotate the plane!
Here is the final result:
Or the original version:)
I always find it interesting to present an algorithm with graphical illustrations. Below are some path-finding algorithms in GIF format:
The typical A-Star algorithm is not very suitable on a feature phone, because you must do with the sorting in the open and close tables. When the CPU frequency is very low (about 100MHz), everything must be done in the fastest way. On the ARM platform, if you take other dependencies into account (limited memory, time for other codes and effiency of virtual machine), A-Star still seemed slow in game, even under optimization with binary heaps. The quickest way with an acceptable outcome which I found at last is similiar to the way of "go along the walls", however, key waypoints are integrated, and following optimization strategies are used:
1.Use memory pools to avoid too much malloc() and free(). Memory allocation needs a lot of time, especially on mobile devices. Programmers should be smart to use them in real time algorithms.
2.Limit path finding steps. For example, if the algorithm doesn't return any result in 32 rounds (that means the units cannot reach their destination in 32 steps), then just stop the present path-finding task to start the next one, and warn the player. This is to avoid those rare yet possible worst situations that may block the task queue.
3.Use a find-and-follow strategy. That means when player selects multiple units and orders them to move toward the same place, Only one unit's path finding will be done, and other units will follow his route.
