Concept of Operations
For anyone who is not familiar with systems engineering lingo and yet still somehow finds themself on this site, a concept of operations (or ConOps (or OpsCon)) is really a just description of how the proposed system will work.
In the case of MARCO, the scope of the project is very narrow because MARCO is envisioned to operate on a myriad of different autonomous vehicles, meaning that its outputs and operations must be stringently defined, standard, and usable in all docking applications.
In other words, I'm not writing the OpsCon for a Skynet-controlled delivery drone network, a refueling satellite in Low-Earth orbit, or a self-driving car docking with a charging station. I'm writing about what happens when your autonomous vehicle says "OK, I'm close enough to my target that I don't feel comfortable getting any closer with my normal navigation protocols. I'm going to wake up my MARCO system now and have it guide me through the final steps of docking."
OpsCon for docking with an unpowered/uncommandable surface:
Mission outset commanding:
When commanded to dock with an unpowered surface, such as a cargo box, electrically disabled vehicle, or unpowered landing pad, MARCO must be provided with the surface's polo file before all else. The polo file specifies surface dimensions, docking mechanism types, and surface target shapes and colors, along with other crucial data products that optimize the docking process. Without a polo file, MARCO has no idea where on the target surface the targets are appearing and consequently cannot return meaningful attitude data.
Target surface visual contact:
Again, the vehicle carrying MARCO is responsible both for bringing itself close enough (depending on target surface size) to its target and placing the target surface in the MARCO camera's field of view. This has been covered to some effect but it bears mentioning again here because this is not a trivial feat when seeking an unpowered target.
Once in the camera's field of view however, it falls to MARCO to guide the vehicle towards the target surface, even if the target is not centered and/or MARCO isn't making LiDAR contact. MARCO will identify candidate shapes in its FOV based on the polo file and if necessary command its craft to move so that it can make better visual contact with potential target surfaces.
Verification, ranging and first acquisition:
When MARCO obtains a good-enough view of the target surface and makes LiDAR contact, it will perform a coarse acquisition, meaning it will use the polo file to find the colored targets on the target surface. When coarse acquisition is complete it will be able to verify the target, meaning it will check the colors of the visible light targets against the polo file to ensure that it is docking with the correct object. This is not a perfect form of validation: colors show up differently in various lighting environments. Each polo surface has an associated 15 digit code in the polo file, so a QR code may be printed on the surface for further validation once the MARCO vehicle is close enough to read it.
Approach and monitoring:
MARCO will continue to perform coarse acquisitions on the target surface until it is close enough to perform fine acquisitions, which yield greater accuracy. Results from these repeated acquisitions are passed to the MARCO computational optimization module, which also takes input from vehicle avionics (speed, attitude data, max slew rate, max acceleration parameters, max docking speed, etc.).
The computational optimization module generates a three-dimensional trajectory function, and outputs Δv, roll, pitch, and yaw commands to vehicle navigation. How the vehicle interprets these commands will vary from application to application, though differing approach trajectories can be obtained from the CO module, certain parameters can be ignored if they are not pertinent, and the navigation system can command an interrupt to MARCO to halt commanding if the vehicle must perform extraneous maneuvers in order to execute a command.
This section is vague and will be discussed in greater detail towards the end of the project, namely when the Computational Optimization module is written.
Docking:
As the MARCO vehicle draws closer, the target surface will occupy an increasing portion of the camera's field of view, to the point where the colored targets may exit the camera's FOV at the edges. For this reason a smaller target is positioned on the polo surface such that this small target is centered in the MARCO camera's FOV when the vehicle is properly aligned with its target surface.
Not a lot can be specified about docking, because docking protocols and mechanisms will vary. the polo file specifies a "docking distance" at which the craft is close enough to its target that the docking mechanism can activate, and a maximum angular error past which the docking mechanism will fail to fasten correctly.
The CO module only sends a "done" flag to vehicle navigation once the requirements specified in the polo file are met, so it falls to the vehicle to decide what to do once MARCO sends this flag.
OpsCon for docking with a commandable surface/vehicle:
This section does not differ greatly from the unpowered target OpsCon, so only the differences will be discussed.
Mission outset commanding:
MARCO does not need the polo file prior to docking procedures. This deceptively powerful feature means that an autonomous vehicle in a MARCO-supported environment can request service from a MARCO-equipped vehicle with no need for open-loop support. In other words, a polo craft can dock with a MARCO craft without any scheduling or intervention outside of the RF link between the two vehicles.
Approach and Monitoring:
As mentioned, an RF link is established between the two vehicles. After this link is established, the polo craft sends its own polo file to MARCO. A polo file contains only around 10KB of data, so just about any modern computer system should be able to store it permanently without much trouble.
During approach, the polo craft streams its own telemetry to MARCO if it can, which is monitored by the CO module. The polo craft may also have IR LEDs which MARCO can command off and on to more easily locate the target surface in its field of view. MARCO may also be able to command the polo craft's navigation systems, allowing the two vehicles to work together towards docking, rather than having only the MARCO vehicle approach.
Docking
The only change to docking protocols is that MARCO may be able to (or may need to) send the "done" flag to both craft once its requirements are met.
In the case of MARCO, the scope of the project is very narrow because MARCO is envisioned to operate on a myriad of different autonomous vehicles, meaning that its outputs and operations must be stringently defined, standard, and usable in all docking applications.
In other words, I'm not writing the OpsCon for a Skynet-controlled delivery drone network, a refueling satellite in Low-Earth orbit, or a self-driving car docking with a charging station. I'm writing about what happens when your autonomous vehicle says "OK, I'm close enough to my target that I don't feel comfortable getting any closer with my normal navigation protocols. I'm going to wake up my MARCO system now and have it guide me through the final steps of docking."
OpsCon for docking with an unpowered/uncommandable surface:
Mission outset commanding:
When commanded to dock with an unpowered surface, such as a cargo box, electrically disabled vehicle, or unpowered landing pad, MARCO must be provided with the surface's polo file before all else. The polo file specifies surface dimensions, docking mechanism types, and surface target shapes and colors, along with other crucial data products that optimize the docking process. Without a polo file, MARCO has no idea where on the target surface the targets are appearing and consequently cannot return meaningful attitude data.
Target surface visual contact:
Again, the vehicle carrying MARCO is responsible both for bringing itself close enough (depending on target surface size) to its target and placing the target surface in the MARCO camera's field of view. This has been covered to some effect but it bears mentioning again here because this is not a trivial feat when seeking an unpowered target.
Once in the camera's field of view however, it falls to MARCO to guide the vehicle towards the target surface, even if the target is not centered and/or MARCO isn't making LiDAR contact. MARCO will identify candidate shapes in its FOV based on the polo file and if necessary command its craft to move so that it can make better visual contact with potential target surfaces.
Verification, ranging and first acquisition:
When MARCO obtains a good-enough view of the target surface and makes LiDAR contact, it will perform a coarse acquisition, meaning it will use the polo file to find the colored targets on the target surface. When coarse acquisition is complete it will be able to verify the target, meaning it will check the colors of the visible light targets against the polo file to ensure that it is docking with the correct object. This is not a perfect form of validation: colors show up differently in various lighting environments. Each polo surface has an associated 15 digit code in the polo file, so a QR code may be printed on the surface for further validation once the MARCO vehicle is close enough to read it.
Approach and monitoring:
MARCO will continue to perform coarse acquisitions on the target surface until it is close enough to perform fine acquisitions, which yield greater accuracy. Results from these repeated acquisitions are passed to the MARCO computational optimization module, which also takes input from vehicle avionics (speed, attitude data, max slew rate, max acceleration parameters, max docking speed, etc.).
The computational optimization module generates a three-dimensional trajectory function, and outputs Δv, roll, pitch, and yaw commands to vehicle navigation. How the vehicle interprets these commands will vary from application to application, though differing approach trajectories can be obtained from the CO module, certain parameters can be ignored if they are not pertinent, and the navigation system can command an interrupt to MARCO to halt commanding if the vehicle must perform extraneous maneuvers in order to execute a command.
This section is vague and will be discussed in greater detail towards the end of the project, namely when the Computational Optimization module is written.
Docking:
As the MARCO vehicle draws closer, the target surface will occupy an increasing portion of the camera's field of view, to the point where the colored targets may exit the camera's FOV at the edges. For this reason a smaller target is positioned on the polo surface such that this small target is centered in the MARCO camera's FOV when the vehicle is properly aligned with its target surface.
Not a lot can be specified about docking, because docking protocols and mechanisms will vary. the polo file specifies a "docking distance" at which the craft is close enough to its target that the docking mechanism can activate, and a maximum angular error past which the docking mechanism will fail to fasten correctly.
The CO module only sends a "done" flag to vehicle navigation once the requirements specified in the polo file are met, so it falls to the vehicle to decide what to do once MARCO sends this flag.
OpsCon for docking with a commandable surface/vehicle:
This section does not differ greatly from the unpowered target OpsCon, so only the differences will be discussed.
Mission outset commanding:
MARCO does not need the polo file prior to docking procedures. This deceptively powerful feature means that an autonomous vehicle in a MARCO-supported environment can request service from a MARCO-equipped vehicle with no need for open-loop support. In other words, a polo craft can dock with a MARCO craft without any scheduling or intervention outside of the RF link between the two vehicles.
Approach and Monitoring:
As mentioned, an RF link is established between the two vehicles. After this link is established, the polo craft sends its own polo file to MARCO. A polo file contains only around 10KB of data, so just about any modern computer system should be able to store it permanently without much trouble.
During approach, the polo craft streams its own telemetry to MARCO if it can, which is monitored by the CO module. The polo craft may also have IR LEDs which MARCO can command off and on to more easily locate the target surface in its field of view. MARCO may also be able to command the polo craft's navigation systems, allowing the two vehicles to work together towards docking, rather than having only the MARCO vehicle approach.
Docking
The only change to docking protocols is that MARCO may be able to (or may need to) send the "done" flag to both craft once its requirements are met.
Comments
Post a Comment