So part of my PhD deliverable is to develop a hardware-in-the-loop simulation model such that the entire suite of software can be tested with a high-fidelity simulation model that mimics the sensors such as the IMU and GPS units. Eventhough I've finalized the simulation model of a 2m glider, the prize is to have miniature helicopter model implemented. The following makes use of the PC only for visual aid and the rest of the simulation. Potentially, although low priority, the matlab visual could be connected to Flight Gear and visualize a 3D model as one. The use of the transmitter and receiver will only to act as control inputs which are then converted to airframe deflections.

The second part of the HILS was a functional test mainly to observe the functioning of the OpenLog board while the IMU and the servos were running. The logging was set at 38400 bps. The aircraft was moved in pitch, roll and yaw to simulate actual flight. The motor was turned on (without propeller attached) to Success Criteria - The logging should not have a loss of data and all IMU and servo variables should be recorded at a rate is for approximately 50hz. Results:  The figures below show that logging was capable at an approximate rate of 50hz. This will be tested in the field prior to the first logged flight.

As mentioned before, the aim of this test was to show that the autopilot board could relay power to the Receiver for servos to work. The InPins of the board connected all Rx signal lines (motor, elevator, rudder, switch (explained later)). The OutPins of the board had the ESC signal line and the corresponding servo signals (elevator and rudder). This configuration could be changed in the future in the event that ailerons are used (different test aircraft). Success Criteria - Displaying transmitter signal pulses coming into the InPins showing on the Serial Monitor.   Results: - The connection test worked albeit for a lengthy debugging exercise. The switch pin on the transmitter was able to enable or disable servo control.The figures of the results are shown below:

As my eyes began to light up thinking that the circuit board that I had built and script that goes along with it, will fast-track the logged flight, I was brought back to earth. Every time the OpenLog board was activated for logging, excessive jitter was experienced by the servos making a successful flight (and landing) impossible. So although the logging was successful (all data was recorded as expected), the jitter in the servos was not. After trying to debug for a few days, I read on the internet above the possible conflict of interrupts of the Arduino when the SoftwareSerial library (for the OpenLog) and the Servo library (Receiver, Transmitter and Servos). One way to solve the problem is to not use the Servo library for servo control and transmit the transmitter signal via digitalWrite command and wait for the next turn to do repeat the process. The problem with this approach though is that if the loop takes too long to come around, the servo will loose holding power and can ...

So having concluded the first few flight tests and achieved a aircraft platform that will be suitable to test the first version of the autopilot, the time came to start the HILS (hardware-in-the-loop simulation) phase. The first step was to make sure that the ESC (electronic speed controller) will be able to supply current and the motor could still be controlled by the transmitter.  The next step was to connect the Rx and Tx to the autopilot board and have the display of signals coming to the board via the Serial Monitor. These inputs will in turn be converted to servo object angle inputs. The reason this is required is two fold: The Arduino IDE already has a servo library. So converting the pulses coming from the input channels to servo angles will be transmitted to the servo). The simplicity of this route will enable easy debugging in the event improper relaying of signals does not occur. The end goal of the HILS test is to establish a level of confidence that the...