Back in 2003, while I was working at Insitu (now part of Boeing), we faced an interesting problem in precise GPS navigation and positioning. We were developing a small unmanned aircraft, called ScanEagle, which ultimately found wide application with US and allied forces in the Middle East and elsewhere, as well as several commercial applications. ScanEagle is a beautiful aircraft and part of its appeal is its unique recovery system. Essentially, we intentionally fly the aircraft into a vertically-suspended cable (which can be hanging from a crane, or suspended over the side of a ship), and snag the cable in a hook at the wingtip. The associated hardware on the aircraft is just a small hook on the wingtip (very light-weight, and very low-drag), and the ability to work with a cable suspended over the side of a ship minimizes the required deck space and enhances safety for personnel on the ship.
Of course, the trick is to hit the cable. The aircraft is buffeted by wind and has only a ten foot wingspan. A ship (if a ship is being used) would be moving as well — and would be rolling side-to-side due to wave action. The goal is to design a system that allows the aircraft to compute its precise relative position and velocity compared to the desired impact point on the cable, multiple times per second (i.e., to account for movement by the aircraft as well as the ship and cable), and build an autopilot that could fly the plane into the cable using this information. In 2003, we had selected a commercial GPS receiver for the aircraft, and a matching differential base station for the ship, that provided 1 cm accuracy using “real-time kinematic” (RTK) positioning. In land-based testing using a crane at an isolated airfield, the system worked exceptionally well.
Unfortunately, when we first attempted a capture at sea, using a small fishing vessel that we had equipped with a boom and cable, we discovered a problem — the vendor’s base station refused to generate RTK differential corrections whenever it was moving!
The vendor could not modify its software to handle a moving base station in time to meet our schedule. Conversely, we did not have the time to switch to a different vendor. Awkward.
The base station could be operated as a normal GPS receiver or as a base station. When operated as a normal receiver, it would generate position and velocity estimates but not RTK corrections. Conversely, in a base station mode, it would generate RTK corrections “at the top of every second,” but held its assumed position fixed. After a few seconds, the growing difference between the assumed (fixed) position and the real position caused an internal cross-check to fail, and the unit would stop generating RTK correction messages.
Experimenting, we learned that we could force the hardware to switch modes very quickly – turning the “base station” function on and off in a fraction of a second — and we could also force it to use a current location (as reported in its “normal” or “rover” mode”) as its assumed (fixed) position. As far as we could tell, the internal tracking loops and accumulators remained locked and functional even when we switched modes. This gave us the elements of our solution. We wrote some external software that would force the device to switch modes in a very particular way. For nine-tenths of every second, we operated the base station as a “normal” GPS rover, generating position and velocity outputs at 10 Hz. These were sent to the plane and used to track the position of the cable suspended from the ship. Then, every time we approached “the top of a second”, we would force the base station receiver into a base station mode using the position estimate generated just a few hundredths of a second previously. The receiver would then obligingly generate an RTK correction at the top of the second — before the internal cross-check could be violated. We would then transmit the RTK correction to the aircraft and switch back to a rover mode to repeat the process. For developing a novel way to operate an off-the-shelf differential base station, Kris Gauksheim and I received US Patent 6,961,018 — Method and Apparatus for Satellite-Based Relative Positioning of Moving Platforms.
Steve was one of our beloved Exclusive Experts for over a decade. He loved working with and through Round Table Group and sent all his cases to be managed by RTG. All of us at Round Table Group will miss him.
Dr. Heppe had over 40 years of experience in the area of telecommunications, electrical engineering, radio/radar, unmanned aircraft, and GPS/GNSS with General Electric Space Division, Stanford Telecommunications, Telenergy, Insitu/Boeing, and independent consultancies.
Our aerospace, aeronautics and aviation expert witnesses, speakers, and consultants are scholars, researchers, and professionals with extensive knowledge in a broad array of disciplines including engineering, materials, systems, failure analysis, and safety. Topics of interest and areas of expertise include but are not limited to aviation, aircraft engineering and design, propulsion, performance, flight dynamics, flight systems, simulations, aircraft failures and accident investigations, and more.
Approximately 100,000 flights are scheduled every day around the world, as well as a number of military, cargo, and air taxi flights. This totals somewhere around 300,000 worldwide daily flights. Our aviation experts have substantive experience working in flight operation, accident investigation, flight training, insurance, and dealing with FAA regulations. These experts have worked at forensic engineering firms, aviation consulting firms, aviation security firms, and in the air force.
Software engineering is the engineering division that develops software products using scientific methods, standards and techniques to create effective and dependable products. By studying the user’s needs when designing, building, and testing new applications, software engineers can achieve their goals of satisfying the user’s needs and create software that is used in offices, schools, and homes every day for work, education, and fun.