10.3.2 Test results
1. When starting the cameras and the Axis both web pages were active. The web pages were used to set up and initialize each camera stream. The camera streams were set up to use the RTSP streaming protocol over UDP. The streams from both cameras were visible and provided live camera feed in the web pages.
2. The connection to each camera was cut following by a reconnection. By refreshing the still camera’s and the Axis’ web page, both streams were up and running as normal.
3. Each camera stream was subscribed to by a VLC media player. When pressing the play button in VLC, the streams showed up after approximately 5 seconds due to buffering. The VLC media player includes functionality enabling recording of a subscribed stream. Hence, both streams were successfully subscribed to and recorded.
4. Each camera stream was subscribed to by the external HMI. When pressing the play button in the external HMI, the streams showed up after approximately 5-10 seconds. This delay was caused by buffering.
5. When cutting the connection to each camera and then reconnect the cameras, the VLC media player stopped subscribing and recording the camera streams. The subscription had to be re-initiated. Also, the external HMI stopped subscribing to the camera streams and the subscription had to be re-initiated.
6. When showing the live streams in the still camera’s and the Axis’ web pages, there are minimal time lags. The still camera stream seemed to be displayed in real-time, while the IR camera had a time lag of a few seconds, which is mainly caused by thermal image processing. When subscribing to the camera streams in a VLC media player, the time lags increased. The still camera had a time lag of approximately two seconds, while the IR camera lagged by 3-5 seconds. When subscribing to the camera streams in the external HMI, both streams had an added time lag relative the VLC streaming of approximately one second. This is because the pre-implemented streaming module in Qt does more buffering than the VLC media player to increase the image frame quality and thus eliminate bad frames caused by package losses.
From these tests we can conclude that the camera streaming works as intended. When the connection is lost, both the external HMI and the VLC media player pause the streaming, hence the streaming has to be re-initialized. In a future version of the object tracking system one should consider implementing a streaming module which would automatically re-subscribe to the camera streams when the connection is up and running after a communication loss. The concerning part of this test is the time lag. If the 5.8GHz radio link between the ground station and the UAV introduces an additional time lag, the quality of the object tracking system could be impaired. Thus, we need to conduct field tests before discussing the time lags’ impairment on the object tracking system any further.
10.4 Piccolo measurements and control action
The control system (engine) should receive and store Piccolo measurements. This includes position, velocity and attitude. The MPC should use the measurements to initialize the MPC’s
Chapter 10. HIL Testing 169
optimization control problem. Before conducting tests with hardware and simulators in the loop we need to check if the Piccolo measurements are received and stored in the engine and used by the MPC. In addition, the control actions calculated by the MPC should be received in the DUNE Piccolo interface. We list the test procedure as follows:
10.4.1 Test procedure
1. Check the connection between the PandaBoard and the controller (computer) running the control system.
2. Distribute the EstimatedState IMC message from the DUNE Piccolo interface, which is subscribed to by the engine. Check if the message is received in the engine, and the measurement information contained in the received message is used to initialize the MPC. The embedded simulator together with the Piccolos and the Piccolo Command Center should be used to provide the measurements sent to the engine by the DUNE Piccolo interface.
3. Check if the measurements are correct. The data provided by the embedded simulator should be used to compare the true measurements with the measurements received in the engine.
4. Check if the DUNE Piccolo interface receives control action from the engine. Sending control action to the gimbal should be tested first by using the SetServoPosition IMC message, then sending WPs to the UAV using the DesiredPath IMC message.
5. Check the accuracy of the WPs generated by the MPC and converted by the GPS transformation algorithms, described in chapter 3.2, by comparing with the UAV’s position measurements generated by simulator.
10.4.2 Test results
1. The connection between the engine and the PandaBoard, which runs the DUNE Piccolo interface, was tested using the bash ping procedure. The connection was up and running, and no communication failures were detected.
2. An EstimatedState IMC message was sent by the DUNE Piccolo interface to the engine. The engine parsed the message and stored the measurements in the shared database. The measurements stored in the shared database were used to initialize the MPC each horizon.
3. Some measurements were wrong. What we thought was position measurements given in latitude, longitude and height were reference points to a local NED frame. By using the reference points and the UAV’s position given in the local NED frame, we calculated the UAV’s position in geographical coordinates (latitude, longitude, height) using the WGS84::displace function, which transforms NED positions to geographical positions. The WGS84::displace function is part of the DUNE library. In addition, the heading measurements were found to be poor. This is because the UAV does not have a compass, thus the Piccolo estimates the heading from GPS position measurements. Because of this, state-feedback was used to provide heading measurements to the MPC. The attitude measurements, roll, pitch and yaw, were given in a body frame using the NED axis