Image-related scanning systems for visual simulation.
Image related scanning systems for visual simulation display for space rendezvous and docking
SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Image related scanning systems for visual simulation display for space rendezvous and docking
Spacecraft on-orbit servicing consists of exchanging components such as payloads, orbital replacement units (ORUs), and consumables. To accomplish the exchange of consumables, the receiving vehicle must mate to the supplier vehicle. Mating can be accomplished by a variety of docking procedures. However, these docking schemes are mission dependent and can vary from shuttle bay berthing to autonomous rendezvous and docking. Satisfying the many docking conditions will require use of an innovative docking device. The device must provide fluid, electrical, pneumatic and data transfer between vehicles. Also, the proper stiffness must be obtained and sustained between the vehicles. A device to accomplish this, the resupply interface mechanism (RIM), was developed. The RIM is a unique device because it grasps the mating vehicle, draws the two vehicles together, simultaneously mates all connectors, and rigidizes the mating devices. The NASA-Johnson Manipulator Development Facility was used to study how compatible the RIM is to on orbit docking and berthing. The facility contains a shuttle cargo bay mockup with a remote manipulator system (RMS). This RMS is used to prepare crew members for shuttle missions involving spacecraft berthing operations. The MDF proved to be an excellant system for testing the RIM/RMS compatibility. The elements examined during the RIM JSC test were: RIM gross and fine alignment; berthing method sequence; visual cuing aids; utility connections; and RIM overall performance. The results showed that the RIM is a good device for spacecraft berthing operations. Mating was accomplished during every test run and all test operators (crew members) felt that the RIM is an effective device. The purpose of the JSC RIM test and its results are discussed.
Two documents provide additional information on system described in "Docking System With Video Feedback" (MFS-28421). First document, "Standard Remote Manipulator System Docking Target Augmentation For Automated Docking", emphasizes use of retroreflectors in target. Second document, "Development Of A Video-Based Automatic Rendezvous And Docking System", describes hardware and software of system. System is video-sensor/electronic-feedback control system. Video camera on active or chasing vehicle views target on passive or chased vehicle. Target illuminated by light-emitting diodes on active vehicle. Image-data-processing subsystem converts video image of target into data on relative position, orientation, linear velocity, and angular velocity of two vehicles. Data then used by maneuver-control subsystem to control approach of active vehicle to passive vehicle.
Shuttle to Space station docking has become an important issue in the last few years. Docking sensors have been proposed that will provide high precision measurements required for the fuel efficient rendezvous and docking of space vehicles. These sensors will also be used for satellite servicing and orbital assembly. The performance of the docking sensors must be tested before they are implemented in a space environment. A Six-Degree-of-Freedom (6-DOF) Test Facility has been developed at the Tracking & Communications Section, Johnson Space Center to test the static and dynamic accuracies of docking sensors. A candidate sensor is evaluated by comparing the sensor's static position and velocity measurements to the more accurate 6-DOF system. The 6-DOF Test Facility's hardware is fully integrated. Software has been developed in-house to support system operation. The system has been tested statically and the operational parameters verified. System accuracies remain to be determined. Dynamic testing of the facility is expected to begin shortly. Several companies such as McDonnell Douglas, Autonomous Technologies, and General Dynamics are scheduled to test sensors in the next few months. The 6-DOF facility will be available for use in November 1991. This presentation describes the subcomponents, operation, and capabilities of the 6-DOF Test Facility. Discussions will be held on system accuracies. Additional applications of the 6-DOF system will also be addressed.
The Satellite Servicing Project at GSFC in the early 80's developed a facility for servicing observatories in orbit when docked on the shuttle. The facility includes a three point docking ring and one or two umbilicals to provide power, data and command capability to docked payloads. This facility was used in the 1984 repair of the Solar Maximum satellite. It will be used for the Hubble repair mission in 1993, and it is planned to be used on the Explorer Platform retrieval mission in 1995 and for servicing AXAF in the late 90's. The basic three point docking mechanisms and umbilical interfaces were adopted by the OMU Project for that vehicle's remote rendezvous and docking mission capability. This would have assured a common interface for a serviceable payload for either shuttle based or remote servicing, i.e., HST. For OMU remote servicing, quick reaction docking latches were under development when that Project was cancelled. Although there is no remote servicing capability being funded at present, the EOS spacecraft configuration does include three pins compatible with the FSS latches as a contingency planning measure.
Shuttle to Space Station docking has become an important issue in the last few years. Docking sensors have been proposed that will provide the high precision measurements required for the fuel efficient rendezvous and docking of space vehicles. These sensors also will be used for satellite servicing and orbital assembly. The performance of the docking sensors must be tested before they are implemented in a space environment. A 6-DOF test facility was developed at the Tracking and Communications Section, JSC, to test the static and dynamic accuracies of docking sensors. A candidate sensor is evaluated by comparing the sensor's static position and velocity measurements to the more accurate 6-DOF system.
The Video Guidance Sensor (VGS) flew on Shuttle mission STS-95 in October of 1998 to test the VGS functional characteristics on orbit. This was the second flight of the VGS, and during these two flights, both long range and short range data were gathered under a variety of lighting conditions, orbital exposure times, and temperatures. The flight experiment sensor was designed to operate from 1.5 meter range out to 110 meter range, with a field-of-view of 16 X 21 degrees. The VGS tracked its target at a 5 Hz rate and returned 6-degree-of-freedom information on the target's position and attitude relative to the sensor. The VGS was mounted in the Shuttle cargo bay, and its target was mounted on the Spartan spacecraft being carried on this mission. The VGS is a sensor designed to allow an automated vehicle to dock with a spacecraft equipped with a passive target. The VGS is a part of an Automated Rendezvous and Capture (AR&C) system being developed and tested by NASA. The orbital testing included operations with the target on the Shuttle's Remote Manipulator System (RMS) near the start of each flight of the VGS, long-range data (on the STS-95 flight) during the Shuttle rendezvous with the Spartan two days later, and some more RMS operations later in the mission. The data returned from the orbital testing included VGS diagnostics, acquisition, and tracking data, RMS positions, hand-held laser range data, tapes of the data from the VGS video camera, and orbital positioning data from the Spartan and the Shuttle to allow correlation of the VGS data with orbital best-estimate-of-truth data. The Video Guidance Sensor performed well in all phases of the testing, and the VGS is being incorporated into the ground testing of a complete automated rendezvous and docking system. Work on the development of the next generation VGS is continuing.
The mission plan of the docking of a United States Apollo and a Soviet Union Soyuz spacecraft in Earth orbit to test compatible rendezvous and docking equipment and procedures is presented. Space experiments conducted jointly by the astronauts and cosmonauts during the joint phase of the mission as well as experiments performed solely by the U.S. astronauts and spread over the nine day span of the flight are included. Biographies of the astronauts and cosmonauts are given.
In the automatic assembly of space stations or the automatic rendezvous and docking of a space-shuttle vehicle with a space station, it is of interest to determine suitable guidance laws for orbital rendezvous which are amenable to on-board implementation. In this paper, various forms of nonlinear guidance laws for automatic orbital rendezvous of two bodies represented by point masses in a central Newtonian gravitational field are derived. A basic requirement is that the approach be smooth and nonoscillatory. The global dynamic behavior of each of the resulting feedback systems is determined analytically and/or by computer simulation.
Various aspects of a rendezvous and docking system using an image dissector detector as compared to a GaAs detector were discussed. Investigation into a gimbled scanning system is also covered and the measured video response curves from the image dissector camera are presented. Rendezvous will occur at ranges greater than 100 meters. The maximum range considered was 1000 meters. During docking, the range, range-rate, angle, and angle-rate to each reflector on the satellite must be measured. Docking range will be from 3 to 100 meters. The system consists of a CW laser diode transmitter and an image dissector receiver. The transmitter beam is amplitude modulated with three sine wave tones for ranging. The beam is coaxially combined with the receiver beam. Mechanical deflection of the transmitter beam, + or - 10 degrees in both X and Y, can be accomplished before or after it is combined with the receiver beam. The receiver will have a field-of-view (FOV) of 20 degrees and an instantaneous field-of-view (IFOV) of two milliradians (mrad) and will be electronically scanned in the image dissector. The increase in performance obtained from the GaAs photocathode is not needed to meet the present performance requirements.
Since 1984 the European Space Agency (ESA) has been working to develop an autonomous rendezvous and docking capability to enable Hermes to dock automatically with Columbus. As a result, ESA (with Matra, MBB, and other space companies) have developed technologies that are directly supportive of the current NASA initiative for Automated Rendezvous and Capture. Fairchild and Matra would like to discuss the results of the applicable ESA/Matra rendezvous and capture developments and suggest how these capabilities could be used together with an existing NASA Explorer Platform satellite to minimize new development and accomplish a cost-effective automatic closure and capture demonstration program.
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.
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.
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.
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 unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. 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.
A selected concept for a geostationary platform is defined in sufficient detail to identify requirements for supporting research and technology, space demonstrations, GFE interfaces, costs, and schedules. This system consists of six platforms in geostationary orbit (GEO) over the Western Hemisphere and six over the Atlantic, to satisfy the total payload set associated with the nominal traffic model. Each platform is delivered to low Earth orbit (LEO) in a single shuttle flight, already mated to its LEO to GEO transfer vehicle and ready for deployment and transfer to GEO. An alternative concept is looked at briefly for comparison of configuration and technology requirements. This alternative consists of two large platforms, one over the Western Hemisphere consisting of three docked modules, and one over the Atlantic (two docked modules), to satisfy a high traffic model. The modules are full length orbiter cargo bay payloads, mated at LEO to orbital transfer vehicles (OTVs) delivered in other shuttle flights, for transfer to GEO, rendezvous, and docking. A preliminary feasibility study of an experimental platform is also performed to demonstrate communications and platform technologies required for the operational platforms of the 1990s.
Argon is a flight-ready sensor suite with two visual cameras, a flash LIDAR, an on- board flight computer, and associated electronics. Argon was designed to provide sensing capabilities for relative navigation during proximity, rendezvous, and docking operations between spacecraft. A rigorous ground test campaign assessed the performance capability of the Argon navigation suite to measure the relative pose of high-fidelity satellite mock-ups during a variety of simulated rendezvous and proximity maneuvers facilitated by robot manipulators in a variety of lighting conditions representative of the orbital environment. A brief description of the Argon suite and test setup are given as well as an analysis of the performance of the system in simulated proximity and rendezvous operations.
On this fourth day of the STS-79 mission, the flight crew, Cmdr. William F. Readdy, Pilot Terrence W. Wilcutt, Mission Specialists, Thomas D. Akers, John Blaha, Jay Apt, and Carl E. Walz, are seen docking with the Mir Space Station. After two hours of pressure and leak checks, the hatches between the two spacecraft is then opened. The two crews are seen greeting one another to begin five days of joint operations. The rendezvous and docking went flawlessly as Readdy flew the orbiter manually through the final 2,000 feet. Docking occurred within seconds of the pre-planned time and flight controllers reported that only slight oscillations were felt through the Orbiter Docking System as the two spacecraft locked together. Within hours of the hatch opening, crew members John Blaha and Shannon Lucid formally swapped places before going to bed with Blaha becoming a member of the Mir-22 crew and Lucid joining the STS-79 crew to wrap up 179 days as a member of the Mir station. Blaha joins Mir 22 Commander Valery Korzun and Flight Engineer Alexander Kaleri on Mir for the next four months. Soon after the crew members completed their welcoming ceremony, they went to work, hauling bags of water and other supplies from the Shuttle's Spacehab module into the Mir. More than 4000 pounds of equipment and logistical supplies will be transferred to the Mir before Atlantis undocks from the space station.