Results for “Voice control” — Page 22

NASA NTRS2012

Using Arm and Hand Gestures to Command Robots during Stealth Operations

Command of support robots by the warfighter requires intuitive interfaces to quickly communicate high degree-of-freedom (DOF) information while leaving the hands unencumbered. Stealth operations rule out voice commands and vision-based gesture interpretation techniques, as they often entail silent operations at night or in other low visibility conditions. Targeted at using bio-signal inputs to set navigation and manipulation goals for the robot (say, simply by pointing), we developed a system based on an electromyography (EMG) "BioSleeve", a high density sensor array for robust, practical signal collection from forearm muscles. The EMG sensor array data is fused with inertial measurement unit (IMU) data. This paper describes the BioSleeve system and presents initial results of decoding robot commands from the EMG and IMU data using a BioSleeve prototype with up to sixteen bipolar surface EMG sensors. The BioSleeve is demonstrated on the recognition of static hand positions (e.g. palm facing front, fingers upwards) and on dynamic gestures (e.g. hand wave). In preliminary experiments, over 90% correct recognition was achieved on five static and nine dynamic gestures. We use the BioSleeve to control a team of five LANdroid robots in individual and group/squad behaviors. We define a gesture composition mechanism that allows the specification of complex robot behaviors with only a small vocabulary of gestures/commands, and we illustrate it with a set of complex orders.

stealth operations↗

NASA NTRS2018

Documenting of Geologic Field Activities in Real-Time in Four Dimensions: Apollo 17 as a Case Study for Terrestrial Analogues and Future Exploration

During the Apollo exploration of the lunar surface, thousands of still images, 16 mm videos, TV footage, samples, and surface experiments were captured and collected. In addition, observations and descriptions of what was observed was radioed to Mission Control as part of standard communications and subsequently transcribed. The archive of this material represents perhaps the best recorded set of geologic field campaigns and will serve as the example of how to conduct field work on other planetary bodies for decades to come. However, that archive of material exists in disparate locations and formats with varying levels of completeness, making it not easily cross-referenceable. While video and audio exist for the missions, it is not time synchronized, and images taken during the missions are not time or location tagged. Sample data, while robust, is not easily available in a context of where the samples were collected, their descriptions by the astronauts are not connected to them, or the video footage of their collection (if available). A more than five year undertaking to reconstruct and reconcile the Apollo 17 mission archive, from launch through splashdown, has generated an integrated record of the entire mission, resulting in searchable, synchronized image, voice, and video data, with geologic context provided at the time each sample was collected. Through www.apollo17.org the documentation of the field investigation conducted by the Apollo 17 crew is presented in chronologic sequence, with additional context provided by high-resolution Lunar Reconnaissance Orbiter Camera (LROC) Narrow Angle Camera (NAC) images and a corresponding digital terrain model (DTM) of the Taurus-Littrow Valley.

APOLLO 17↗

NASA NTRS2012

DataComm in Flight Deck Surface Trajectory-Based Operations

The purpose of this pilot-in-the-loop aircraft taxi simulation was to evaluate a NextGen concept for surface trajectory-based operations (STBO) in which air traffic control (ATC) issued taxi clearances with a required time of arrival (RTA) by Data Communications (DataComm). Flight deck avionics, driven by an error-nulling algorithm, displayed the speed needed to meet the RTA. To ensure robustness of the algorithm, the ability of 10 two-pilot crews to meet the RTA was tested in nine experimental trials representing a range of realistic conditions including a taxi route change, an RTA change, a departure clearance change, and a crossing traffic hold scenario. In some trials, these DataComm taxi clearances or clearance modifications were accompanied by preview information, in which the airport map display showed a preview of the proposed route changes, including the necessary speed to meet the RTA. Overall, the results of this study show that with the aid of the RTA speed algorithm, pilots were able to meet their RTAs with very little time error in all of the robustness-testing scenarios. Results indicated that when taxi clearance changes were issued by DataComm only, pilots required longer notification distances than with voice communication. However, when the DataComm was accompanied by graphical preview, the notification distance required by pilots was equivalent to that for voice.

Bakowski, Deborah L.↗

NASA NTRS2012

DataComm in Flight Deck Surface Trajectory-Based Operations

The purpose of this pilot-in-the-loop aircraft taxi simulation was to evaluate a NextGen concept for surface trajectory-based operations (STBO) in which air traffic control (ATC) issued taxi clearances with a required time of arrival (RTA) by Data Communications (DataComm). Flight deck avionics, driven by an error-nulling algorithm, displayed the speed needed to meet the RTA. To ensure robustness of the algorithm, the ability of 10 two-pilot crews to meet the RTA was tested in nine experimental trials representing a range of realistic conditions including a taxi route change, an RTA change, a departure clearance change, and a crossing traffic hold scenario. In some trials, these DataComm taxi clearances or clearance modifications were accompanied by 'preview' information, in which the airport map display showed a preview of the proposed route changes, including the necessary speed to meet the RTA. Overall, the results of this study show that with the aid of the RTA speed algorithm, pilots were able to meet their RTAs with very little time error in all of the robustness-testing scenarios. Results indicated that when taxi clearance changes were issued by DataComm only, pilots required longer notification distances than with voice communication. However, when the DataComm was accompanied by graphical preview, the notification distance required by pilots was equivalent to that for voice.

NextGen↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRSDate not supplied

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

NASA NTRSDate not supplied

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

NASA NTRS2018

Nasa's Launch Communications Ground Segment for the 21st Century Florida Spaceport

The National Aeronautics and Space Administration (NASA) Near Earth Network (NEN) Project is implementing a new launch communications ground segment to provide services for the next generation of human and robotic space exploration systems. It will deliver unique and advanced capabilities to accelerate the transformation of Kennedy Space Center into a multi-user spaceport in cooperation with the United States Air Force (USAF). The project has leveraged commercial technologies and remote operations concepts matured in NASAs orbiting satellite ground systems to achieve dramatic lifecycle cost efficiencies as compared to the space shuttle-era ground segment. The purpose of this paper is to discuss the development history, capabilities and anticipated use cases of the NEN Launch Communications Segment (NEN LCS).The NASA Kennedy Space Center is co-located with the USAF Eastern Launch Range at Cape Canaveral, Florida. The USAF operates two launch communications ground stations, but they are not designed to transmit voice, commands or other data to the launch vehicle or astronauts. The bi-directional uplink-downlink communications responsibility for human missions has historically resided with the Goddard Space Flight Center in Greenbelt, Maryland. Several market analyses and feasibility studies investigating concepts to provide NASAs next generation launch communications services were performed during the Constellation Program prior to its cancellation in 2009, and as part of the Kennedy Space Centers follow-on efforts to transform itself into a 21st century multi-user spaceport. In 2012, the Kennedy Space Center and the USAF 45th Space Wing jointly led a study to analyze the market needs of current and future launch systems and assess the operational deficiencies of the Eastern Range infrastructure. The study team issued several recommendations, two of which ultimately became driving operational capability requirements for the NEN LCS: increased telemetry data rates of at least 20 Mbps, and S-band uplink capability. Additional capabilities identified in the requirements development process include spread spectrum modulation support, LDPC 12 and 78 error correction codes, support for IRIG-106 and CCSDS data formats, automated best source selection, and Space Link Extension (SLE) services for data distribution. The NEN LCS is comprised of two permanent ground stations, the new Kennedy Uplink Station (KUS) and refurbished Ponce de Leon (PDL) station. Both stations are remotely operated from the Global Monitor and Control Center at Wallops Flight Facility. This core architecture is extensible through host-tenant arrangements with the U.S. Air Force and deployable assets, enabling agile, tailored and robust solutions to meet the needs of civil, commercial or military customers. The NEN LCS has three use cases:1.To provide agile, tailored and robust launch communications solutions to Florida spaceport customers2.To provide orbital communications services to near-earth customers 3.To provide an experimental proving ground for Space Mobile Network concepts and technologies The NEN LCS driving mission is to support the bi-directional link with the Orion crew capsule and two 20 Mbps telemetry links from the Space Launch System core stage on Exploration Mission-1, the first integrated flight of NASAs flagship human exploration systems.

Roberts, Christopher J.↗

NASA NTRS2000

Architectural Methodology Report

The establishment of conventions between two communicating entities in the end systems is essential for communications. Examples of the kind of decisions that need to be made in establishing a protocol convention include the nature of the data representation, the for-mat and the speed of the date representation over the communications path, and the sequence of control messages (if any) which are sent. One of the main functions of a protocol is to establish a standard path between the communicating entities. This is necessary to create a virtual communications medium with certain desirable characteristics. In essence, it is the function of the protocol to transform the characteristics of the physical communications environment into a more useful virtual communications model. The final function of a protocol is to establish standard data elements for communications over the path; that is, the protocol serves to create a virtual data element for exchange. Other systems may be constructed in which the transferred element is a program or a job. Finally, there are special purpose applications in which the element to be transferred may be a complex structure such as all or part of a graphic display. NASA's Glenn Research Center (GRC) defines and develops advanced technology for high priority national needs in communications technologies for application to aeronautics and space. GRC tasked Computer Networks and Software Inc. (CNS) to describe the methodologies used in developing a protocol architecture for an in-space Internet node. The node would support NASA:s four mission areas: Earth Science; Space Science; Human Exploration and Development of Space (HEDS); Aerospace Technology. This report presents the methodology for developing the protocol architecture. The methodology addresses the architecture for a computer communications environment. It does not address an analog voice architecture.

Dhas, Chris↗

NASA NTRS2005

Artificial Neural Network Test Support Development for the Space Shuttle PRCS Thrusters

A significant anomaly, Fuel Valve Pilot Seal Extrusion, is affecting the Shuttle Primary Reaction Control System (PRCS) Thrusters, and has caused 79 to fail. To help address this problem, a Shuttle PRCS Thruster Process Evaluation Team (TPET) was formed. The White Sands Test Facility (WSTF) and Boeing members of the TPET have identified many discrete valve current trace characteristics that are predictive of the problem. However, these are difficult and time consuming to identify and trend by manual analysis. Based on this exhaustive analysis over months, 22 thrusters previously delivered by the Depot were identified as high risk for flight failures. Although these had only recently been installed, they had to be removed from Shuttles OV103 and OV104 for reprocessing, by directive of the Shuttle Project Office. The resulting impact of the thruster removal, replacement, and valve replacement was significant (months of work and hundreds of thousands of dollars). Much of this could have been saved had the proposed Neural Network (NN) tool described in this paper been in place. In addition to the significant benefits to the Shuttle indicated above, the development and implementation of this type of testing will be the genesis for potential Quality improvements across many areas of WSTF test data analysis and will be shared with other NASA centers. Future tests can be designed to incorporate engineering experience via Artificial Neural Nets (ANN) into depot level acceptance of hardware. Additionally, results were shared with a NASA Engineering and Safety Center (NESC) Super Problem Response Team (SPRT). There was extensive interest voiced among many different personnel from several centers. There are potential spin-offs of this effort that can be directly applied to other data acquisition systems as well as vehicle health management for current and future flight vehicles.

Lehr, Mark E.↗

NASA NTRS2008

Space-Based Range

Space-Based Range (SBR), previously known as Space-Based Telemetry and Range Safety (STARS), is a multicenter NASA proof-of-concept project to determine if space-based communications using NASA's Tracking and Data Relay Satellite System (TDRSS) can support the Range Safety functions of acquiring tracking data and generating flight termination signals, while also providing broadband Range User data such as voice, video, and vehicle/payload data. There was a successful test of the Range Safety system at Wallops Flight Facility (WFF) on December 20, 2005, on a two-stage Terrier-Orion spin-stabilized sounding rocket. SBR transmitted GPS tracking data and maintained links with two TDRSS satellites simultaneously during the 10-min flight. The payload section deployed a parachute, landed in the Atlantic Ocean about 90 miles downrange from the launch site, and was successfully recovered. During the Terrier-Orion tests flights, more than 99 percent of all forward commands and more than 95 percent of all return frames were successfully received and processed. The time latency necessary for a command to travel from WFF over landlines to White Sands Complex and then to the vehicle via TDRSS, be processed onboard, and then be sent back to WFF was between 1.0 s and 1.1 s. The forward-link margins for TDRS-10 (TDRS East [TDE]) were 11 dB to 12 dB plus or minus 2 dB, and for TDRS-4 (TDRS Spare [TDS]) were 9 dB to 10 dB plus or minus 1.5 dB. The return-link margins for both TDE and TDS were 6 dB to 8 dB plus or minus 3 dB. There were 11 flights on an F-15B at Dryden Flight Research Center (DFRC) between November 2006 and February 2007. The Range User system tested a 184-element TDRSS Ku-band (15 GHz) phased-array antenna with data rates of 5 Mbps and 10 Mbps. This data was a combination of black-and-white cockpit video, Range Safety tracking and transceiver data, and aircraft and antenna controller data streams. IP data formatting was used.

Source record↗

DOE OSTI2020

User Access to Scientific Facilities via 5G: A Cyber Security Thought Experiment

5G is more than an over-the-air radio technology upgrade. It is a strategy to extend Mobile Network Operator service offerings beyond traditional voice, instant messaging and Internet access. 5G Mobile Network Operators will offer new telecommunication services that include enhanced guarantees of confidentiality, integrity and availability. How could such services change the way Science collaborations connect scientists to supercomputers and other scientific facilities? Current scientific collaborations implicitly trust cloud service providers to securely store and process data. The perceived risks of outsourcing Science data security are counterbalanced by assurances that cloud providers operate at a scale that allows them to implement security measures impractical for Science collaborations (e.g. continuous system administrator behavioral monitoring and strict individual separation of duties). If that is true for a cloud service provider like Amazon Web Services (2018 revenue: $25.7 billion), could it also be true for Mobile Network Operators like Verizon Wireless (2018 revenue: $91.7 billion) or AT&T Mobility (2018 revenue: $71.3 billion)? DOE Leadership Class supercomputer facility users currently access them from the public Internet via Secure Shell. The sponsors and operators of the supercomputer facilities have determined that the public Internet path between the Scientist’s Device and the Login Node does not natively provide enough confidentiality or integrity to protect those communications. Therefore, the facilities achieve additional confidentiality and integrity by requiring Secure Shell encryption across those untrusted network paths. Using 5G Network Slice technology, a Mobile Network Operator may offer communication services between supercomputer users and facilities that natively provide confidentiality and integrity guarantees. Sponsors and operators of supercomputer facilities may determine that these guarantees provide enough confidentiality and integrity to protect those communications. If so, a 5G Network Slice could replace an SSH session running over the public Internet. Finally, this use case could be extended to other Office of Science user facility access requirements. Consider microscopy instruments at (e.g.) the Center for Nanoscale Materials or the Environmental Molecular Sciences Laboratory. The embedded systems controlling such instruments may not always support encrypted network access technologies like SSH. 5G Network Slices may offer an alternative to current VPN or SSH tunneling techniques, with additional benefits like guaranteed minimum bandwidth.

5G↗

NASA NTRS2010

Enabling IP Header Compression in COTS Routers via Frame Relay on a Simplex Link

NASA is moving toward a networkcentric communications architecture and, in particular, is building toward use of Internet Protocol (IP) in space. The use of IP is motivated by its ubiquitous application in many communications networks and in available commercial off-the-shelf (COTS) technology. The Constellation Program intends to fit two or more voice (over IP) channels on both the forward link to, and the return link from, the Orion Crew Exploration Vehicle (CEV) during all mission phases. Efficient bandwidth utilization of the links is key for voice applications. In Voice over IP (VoIP), the IP packets are limited to small sizes to keep voice latency at a minimum. The common voice codec used in VoIP is G.729. This new algorithm produces voice audio at 8 kbps and in packets of 10-milliseconds duration. Constellation has designed the VoIP communications stack to use the combination of IP/UDP/RTP protocols where IP carries a 20-byte header, UDP (User Datagram Protocol) carries an 8-byte header, and RTP (Real Time Transport Protocol) carries a 12-byte header. The protocol headers total 40 bytes and are equal in length to a 40-byte G.729 payload, doubling the VoIP latency. Since much of the IP/UDP/RTP header information does not change from IP packet to IP packet, IP/UDP/RTP header compression can avoid transmission of much redundant data as well as reduce VoIP latency. The benefits of IP header compression are more pronounced at low data rate links such as the forward and return links during CEV launch. IP/UDP/RTP header compression codecs are well supported by many COTS routers. A common interface to the COTS routers is through frame relay. However, enabling IP header compression over frame relay, according to industry standard (Frame Relay IP Header Compression Agreement FRF.20), requires a duplex link and negotiations between the compressor router and the decompressor router. In Constellation, each forward to and return link from the CEV in space is treated independently as a simplex link. Without negotiation, the COTS routers are prevented from entering into the IP header compression mode, and no IP header compression would be performed. An algorithm is proposed to enable IP header compression in COTS routers on a simplex link with no negotiation or with a one-way messaging. In doing so, COTS routers can enter IP header compression mode without the need to handshake through a bidirectional link as required by FRF.20. This technique would spoof the routers locally and thereby allow the routers to enter into IP header compression mode without having the negotiations between routers actually occur. The spoofing function is conducted by a frame relay adapter (also COTS) with the capability to generate control messages according to the FRF.20 descriptions. Therefore, negotiation is actually performed between the FRF.20 adapter and the connecting COTS router locally and never occurs over the space link. Through understanding of the handshaking protocol described by FRF.20, the necessary FRF.20 negotiations messages can be generated to control the connecting router, not only to turn on IP header compression but also to adjust the compression parameters. The FRF.20 negotiation (or control) message is composed in the FRF.20 adapter by interpreting the incoming router request message. Many of the fields are simply transcribed from request to response while the control field indicating response and type are modified.

Nguyen, Sam P.↗

NASA NTRSDate not supplied

Transcribing Air Traffic Control System Command Center Planning Telecons Using Cloud-Based Automatic Speech Recognition

This paper addresses the challenge of using Automatic Speech Recognition (ASR) technology to transcribe regular teleconferences that happen between FAA Air Traffic Control System Command Center (ATCSCC) planners, stakeholders and air users. These planning teleconferences (aka telecons or planning webinars) are an integral part of managing air traffic in the U.S. National Airspace System (NAS). In particular, the meetings facilitate the creation and modification of various traffic management initiatives (TMIs), that are used to regulate the flow of air traffic. This is typically a human intensive process, requiring specialists to listen to the entire meeting audio (10-20 minutes duration) and inferring the state of the NAS (e.g., weather phenomenon) that was discussed. It would be advantageous to have digital transcripts of the audio and have useful information (e.g., related to TMIs) automatically extracted from the transcripts. In this regard, we are exploring the adoption of state-of-the-art speech to text and Natural Language Processing (NLP) tools that will achieve our objective of digitizing the webinar audio. Unfortunately, the highly technical phraseology present in the audio and limited data availability for model building make ASR difficult. To overcome this challenge, we have taken the critical first step in creating a human transcription dataset from ~20 hours of speech in the ATCSCC audio with the help of subject matter experts. A novelty of our work is the creation of a ground truth transcription dataset for ATCSCC teleconference webinars, which is particularly important for Aviation domain-specific NLP tasks. Using Microsoft Speech Studio, a cloud-based ASR platform, we have fine-tuned the English pre-trained ASR models (available in speech studio) and achieved an average word error rate (WER) of 6.81%. The baseline ASR also provides a digital version of each planning webinar, making it accessible and text-searchable for future references. Additionally, the transcriptions can serve as a bridge between raw audio data and a range of text-based NLP tasks, such as named entity recognition (NER) and intent classification, potentially enhancing the digital footprint of the webinars and other connected data sources. Our work has several potential applications. Firstly, the transcriptions can be analyzed to understand the complex decision process of creating, implementing and modifying TMIs and may also contribute to TMI prediction services. Secondly, our dataset and model can be used to develop more accurate ASR systems for aviation-specific language, which can bring about digital communication in the aviation industry (and aid current “voice only” communications, which are inherently error-prone). Lastly, the transcriptions themselves can be used as a valuable resource for training other NLP models.

Stephen S. B. Clarke↗