From Fledgling to Flight

The UAV VTOL application requires continuously precise and accurate relative positioning of the helicopter and the ship. The solution implemented on the Little Bird uses GNSS positioning and inertial navigation and is a modernization of a system previously demonstrated in 2005.

Both the ship and the helicopter were outfitted with SPAN-SE-dual antenna GNSS/INS receivers. The relative RTK solutions was provided by NovAtel's ALIGN® algorithm. Postprocessing of the CORS data with the shipboard and helicopter GNSS/INS data used the Inertial Explorer® post-processing software from NovAtel's Waypoint® Products Group. The accompanying sidebar describes the evolution of the integrated navigation solution to achieve the relative navigation used in the Little Bird tests.

In landing a helicopter aboard a moving ship, the quality of the attitude solution on the ship's system plays the most significant role in determining the overall relative accuracy. The ship's GNSS/INS system is mounted in a convenient location away from the landing pad, but the landing pad is the true point of interest. Similarly, the landing gear is the point of interest on the helicopter, not the location of the inertial measurement unit (IMU).

Both GNSS/INS systems must project their solutions from the IMU to the point of interest. To implement this coordinate projection, the offset vector from the IMU must be measured in the IMU frame, and the rotation matrix between the IMU reference frame and the GNSS's Earth-centered Earth-fixed (ECEF) frame must be known. The accuracy of the solution at the point of interest therefore depends on the quality of the measured offset as well as the quality of the rotation matrix from the IMU frame to the ECEF frame.

This rotation matrix is maintained as part of the INS solution. The quality of the rotation matrix is very dependent on the quality of the initial INS alignment (i.e., finding the IMU's orientation with respect to gravity and north), and the overall convergence of the GNSS/INS solution. The longer the offset vector is to the landing pad, the larger the effect of the rotation matrix errors (i.e., a classic pointing error in survey terminology).

Attitude errors in GNSS/INS are best observed with vehicle dynamics. In particular, horizontal accelerations allow the azimuth error to be observed and controlled. Depending on the size and speed of the vessel, the dynamics observed aboard a ship can be very low, leading to degradation in the azimuth solution.

The initial alignment poses another challenge as well. A stationary coarse alignment can be performed with tactical grade IMUs, but only when the system is truly stationary. A transfer alignment can be performed with the GNSS course-over-ground azimuth and pitch, but only when the vehicle's forward direction of travel is aligned to the IMU's forward axis (or there is a fixed, known offset between them).

With a ship or helicopter, these alignment conditions cannot be assured due to crab angles, the angular difference between heading and actual ground path. A ship will often be moving enough to prevent a stationary alignment and its movement without any crab angle cannot be guaranteed. Even if an alignment is achieved, the dynamics will likely be too low for good GNSS/INS convergence. This will degrade the quality of the projected coordinate at the landing pad, which is where the helicopter is aiming.

The helicopter system suffers a similar challenge in initial alignment. Helicopters are not an ideal platform to use a transfer alignment from GNSS course-over-ground measurements, due to their maneuverability.

To solve the initial alignment problem (on ship and helicopter) and to address the attitude error convergence/observability problem (on the ship), the GNSS/INS was augmented with a second GNSS receiver and antenna, using the fixed baseline implementation of the relative RTK algorithm. The ship's GNSS/INS has two GNSS antennas associated with it, as does the helicopter's GNSS/INS. The offset vector from the IMU to both antennas must be measured and input.

The pitch and heading of the baseline between the two antennas is used for the initial INS alignment. Because the roll angle cannot be observed with just two antennas, it is assumed to be zero in the initial alignment. After alignment, the GNSS azimuth is used as a heading update to the INS.

This solution is critical for the ship system, because the ship will be experiencing low dynamics, making the attitude errors less observable. For the helicopter system, the GNSS azimuth updates are not as vital because the helicopter maneuvers much more and its attitude errors are generally observable via the vehicle dynamics.

Ships at sea, however, exhibit the following helideck motions: pitch, roll, yaw, heave, sway, and surge. Ships also don't move across the Earth in the same direction as their heading due to local water currents, a factor that must be accommodated in the flight control laws. Moreover, conducting terminal flight operations in the intended operational environment must also deal with the wind turbulence generated by a ship's superstructure. These factors created a requirement for safety pilot training in a maritime environment.

Landing the H-6U helicopter safely on a moving yacht had everything to do with the relative dimensions of both and the adjacent physical structures.

The Allure Shadow, a yacht based in Fort Lauderdale, Florida, is equipped with a helipad that measures 34 feet wide by 50 feet long and is surrounded on three sides by horizontal safety nets, which are raised about 5 inches above the helipad surface. At the forward edge of the helipad is an overhang from a pool deck located next to and above the landing zone.

The pool deck overhang presents a contact hazard for the helicopter main rotor system while the helipad's safety net system presents a contact hazard for the helicopter's tail structure.

An H-6U helicopter has the following dimensions: main rotor diameter, 27.5 feet; tail rotor diameter, 4.75 feet; total helicopter length, main rotor tip to rotor tip, 32.3 feet. The stinger, the lowest part of the H-6U's vertical stabilizer, is approximately 2.5 feet above the landing surface.

Advisers recommended a minimum of 3 feet lateral clearance from the stinger to the edge of the helipad where the safety net frames protruded upwards, and a minimum of 10 feet lateral clearance between the main rotor blades and the closest ship structure.

A careful survey of the helipad yielded a zone of approximately five feet fore and aft in which the safety pilot could allow the H-6U to land and insure safe structural clearance. Simple but highly effective markers were installed to create a visual cue environment that could enhance the flight crew's judgment regarding a safe landing zone. The proximity of the helicopter rotors to the yacht structure, while fairly tight compared to dimensions generally found on DoD vessels, is common in the super yacht world.

Test Setup and Description

The ULB team used survey instruments to measure the lever arms (offset vector from the IMU to the GNSS antenna) and point-of-interest offset vectors while the ship was docked. During the survey, it was exceptional windy, leading to ship motion and lower accuracy lever-arm determinations than desired.

The H-6U was equipped with the primary antenna on the “T” tail and a secondary antenna on the nose. A laser micrometer mounted on the belly center would measure absolute displacement of the belly above the heli-deck on initial touchdown and the final height after the landing gear had settled.

Data links transmitted differential correction data between the ship and the helicopter and also transmitted the real-time relative ship-to-helicopter solution, output in the log RELINSPVA, back to the “command center” via radio link. The GNSS/INS receivers on board the Allure Shadow logged raw inertial and GNSS data in order to be able to post-process the ship and helicopter conventional RTK trajectories. In post-processing data collected at the National Geodetic Survey's continuously operating reference station (CORS) “LAUD” located near Fort Lauderdale about 25 kilometres from the test area.

The accuracy of each post-processed trajectory was about three centimetres. For performance analysis, the real-time ship-to-helicopter relative position vector was compared to the post-processed ship-to-helicopter relative position vector.

The true test of the system's performance, however, came in the real-time testing as demonstrated in several successful autonomous landings. Tests were undertaken on July 4 and 5, 2012, at sea off the coast from Fort Lauderdale, Florida.

Test Results from July 4

For most of the morning, the aircraft performed maneuvers behind the boat, following its movement. Although a sea state of 3 or 4 (wave height between 0.5 and 2.5 metres) would have been preferred during the trials, the water surface was essentially flat, sea state 0. The H-6U was also allowed to approach the landing pad and hover over the landing point to provide a sufficient confidence level that the system was functioning as expected. The aircraft then performed a single automated landing before returning to the airport for fuel. Figure 1 shows the trajectories of the boat (green) and the aircraft (red) during these operations.

The aircraft autonomously landed on the helipad at GPS time 316350-316772 seconds. The GNSS/INS system on the helicopter reported a real-time relative position to the helipad center of 0.024m North, -0.028m East, and 1.09m Up. The helicopter belly height measured was approximately 64 centimetres; so, the real-time results seem to have about 40 centimetres of vertical error, which matches the vertical error of the lever arm.

In post-processing, the new lever arm was used and the average relative position values of the helicopter on the landing pad were -0.383m North, -0.298 East, and 0.771 Up, which agrees much better to the known helicopter belly height. Figure 2 shows the difference between the real-time and post-processed relative position solutions as the helicopter was landed. Recall that the real-time solution shows about 35 centimetres of height error due to the lever arm used in real-time.

The nature of the test program did not allow for extensive tuning of the automated flight control system to respond in an optimal fashion to the navigation data input. Nevertheless, the results from the initial test program were impressive. Table 1 presents the difference between the H-6U position at 10 feet above the helipad and after landings to the helipad during one sortie.

The radar altimeter output compared very favorably with the RTK solution, as shown in Figure 3.

Conclusion

Maritime flight tests during the summer of 2012 demonstrated the accuracy of the navigation solution, as well as the integration of the navigation solution with the automated flight control system on the Boeing H-6U Unmanned Little Bird.

A total of 16 fully autonomous landings and 13 fully autonomous takeoff/departures comprised this latest effort, with the flight crew closely monitoring the controls and the aircraft position when the aircraft was in close proximity to the deck.

In all, seven sequential days were required to accomplish the deck qualifications of two Boeing test pilots, integrate and debug all systems and software, and carry out maritime terminal operations until the operation became routine. These efforts demonstrated the value of the Unmanned Little Bird program's optionally manned system architecture.

The initial development of “moving baseline” technology began in late 2004 and had the following requirements.

1. High update rate (i.e., 100 hertz) for position and attitude
2. Attitude accuracy of both vehicles to ±1 degree
3. Capability of providing continuous position data of the touch down point (TDP) on the vessel when the TDP is not collocated with the navigation system's GNSS antenna or IMU.
4. Relative position accuracy of 0.5 metres at 1 sigma.

Several methods were explored during this development. The first - and simplest - technique was to generate an independent single-point differenced solution. Because the INS essentially provides a filtered output of the GNSS solution, the relative accuracies between two INS solutions should be lower than that of two GNSS solutions.

The second method eliminated the static base station requirement and solved for the offset vector between the two moving antennas using typical double-difference techniques. The INS filter of the second body was then updated with the single-point position plus the relative vector of the first body. This provided a means to “tie” the two systems together, relatively but very accurately.

The third technique was a combination of the first two cases. If the INS solution is a “smoother” version of the GNSS solution, then why not update the second body with the INS position plus the relative vector of the first.

Finally, during the development and testing of these methods it was observed that the relative errors in the position between epochs were highly correlated. Therefore, a method was developed for computing a post-update correction to be applied directly to the output of the two integrated navigation systems. This correction varied slowly thus allowing it to be applied during the intervals in between the low rate RTK solutions.

Jump ahead eight years: the Little Bird project had received some funding and was getting ready for another test. NovAtel had to bring the “moving baseline” up to date in order to work with the newer hardware (SPAN-SE).

The unique construction of the SPANSE meant that two sets of firmware had to be modified for the completion of this application. A PowerPC board was developed to take on the task of running all the INS-specific filtering and functionality. This freed up the OEMV-3 processor to handle only the GNSS portion of the overall system: including the relatively low rate, onehertz, position updates used by the INS filter running on the SPN board.

Furthermore, adding an OEMV-3 can provide the capability of generating ALIGN heading updates from a single enclosure. This heading solution can also be passed back to the internal SPAN board via designated serial ports to allow for further updates to the INS filter.

Figure 1 shows the outline of the data flow for the overall system.

The local INS solution, computed by the filter running on the SPAN board, is repackaged in to an external  data packet. The data packet is then transmitted to the OEMV-3, where it is used by the various tasks depending on whether the SPAN-SE is currently operating as a Master or Remote. A matcher task is used to handle all of the RTK functionality needed to derive the carrier phase relative positioning and repackage the solution into another external message to be transmitted back to the local SPAN board for further processing and output. The relative solution with respect to the local station is available from either the master or the remote. For example, the relative solution output from the remote station will be the opposite of that same solution output at the master station.

As one can see, the major complication of this project was simply coordinating and matching the myriad of required data between not only the two external systems but also the subsystems inherent to the SPAN-SE design itself.

In order to account for the usersupplied eccentric offset, the master SPAN-SE was set up to transmit the INS position at the antenna as well as the position, velocity, and attitude corrected to the eccentric offset.

The underlying algorithms are quite simple and are based on two well-known techniques. First, computation of the RTK vector using double-differenced carrier phase observations and least-squares ambiguity decorrelation adjustment (LAMBDA), the well-documented method for the integer estimation of ambiguities proposed by Professor Peter Teunissen of Delft University, and second, fusion of GNSS/INS using an extended Kalman filter to control the INS errors via GNSS observables. The RTK translation vector is applied to the filtered master INS estimate and used as a noise-reduced position update to control the remote INS errors. Because the transfer system of the Kalman filter is governed by the input variance, was increased the covariance of the position update by a factor of three to help ensure that computed gains were properly distributed.

So, a position update at the remote receiver's location, where RP/MP is Remote Position and Master Position, respectively, has these elements:

Update = MPins + RTK Vector

Update Covariance = 3.0*MPins Covariance

If the RTK vector is not available, the remote will continue to perform local position updates using the single point least-squares position update and associated covariance.

Inertial errors at both remote and master vehicles typically vary slowly, which means the relative error between the two systems is also slowly varying.

With the presence of a valid RTK vector, the relative INS position can be corrected by differencing the two post-update INS positions from the RTK vector. This in turn will provide information about the amount of drift that has been experienced between the two INS systems. The correction can then be applied directly back to the post-update remote INS position.

It should be emphasized that the corrections are applied to the output of the inertial system, and not to the inertial system parameters themselves, as it will cause all the other inertial system components to become unobservable.

So, the steps in applying a remote relative position correction, are as follows:

Correction = RTK - (RPins - MPins)

RPcor = RPins + Correction

Relative Position = RPcor - MPins

The correction is used to remove the bulk of the relative error caused by the slowly varying wander noticed between the two INS systems. It will typically be updated at the requested rate, but will continue to be used for a period of up to five seconds.

After five seconds the amount of potential error in the correction could be as much as the singlepoint relative error; so, it will no longer provide any additional benefit and could actually begin corrupting the solution further.