We cannot guarantee Internet connectivity at the Stage 3 final event. If you plan to use a cloud-based component, consider designing an offline backup alternative to collect the required data. You may use other wireless protocols or methods to link the drone and the command server. The only required Wi-Fi link is between the sensor modules and the drone.
No, NIST will not be providing the command station in these stages. You must provide the computer or resource to run the command server and the collection method on the UAV. NIST is not providing it in Stage 2 or 3. This component may be a laptop, computer, phone, cloud resource, etc. You may use any software or hardware on the command server as long as it can provide the evaluation requirements. For evaluation, you must collect two things from the drone: pictures and JSON data. The Stage 2 guidance document explains these tasks’ procedures in depth, so we strongly advise checking the Stage 2 guidance document as it details the requirements for submission and scoring. We are encouraging the creative display of sensor and drone photo data; however, for scoring criteria, you will just need to submit the number of data elements collected as JSON objects as well as the requested photo data.
The requirements for Stage 3 will be very similar to the Stage 2 tests, but the parameters regarding the collected sensor data will be more defined, and flight tests will be more demanding. You will be required to collect data from sensors that NIST deploys and deliver that data to a command center computer. Similarly, we will allow the use of your own computer as the command center but will require to deliver data in a similar format as Stage 2.
Not necessarily. Some past winners have used their ranking and solution to advertise on their own. NIST will often times invite the winners to conferences as they become available but, again, there is nothing designated for this UAS challenge.
For every improvement, you can submit a revision to increase your score. The amount of reuploads/revisions is up to the participant. Also, please note, this is not considered a new submission, you would be editing your one submission and reuploading the new improvements you have made.
No there is not, there are no restrictions on size. As long as it is FAA 107 compliant. Also, keep in mind ease of use for the end user, that being first responders. For this challenge, we are interested in small UAS, something a first responder may already have in their vehicle. Our stakeholders are first responders, so we are looking to innovate with the end user in mind; that is our goal from a research perspective. Additionally, working with the sub-55 lbs was also to alleviate some of the cost for competitors.
Yes, just make sure the sponsorship fits within the eligibility and challenge rules. Refer to Terms and Conditions in the Official Rules. You are allowed to collaborate with other companies, individuals, etc.
Contestants have options to win awards in Best-in-Class and/or be invited to Stage 3 without completing all five tests or being Top 10 on the Leaderboard. As stated in the Official Rules, “from the Main Contest, up to the top 10 Stage 2 winners selected by the judge panel will be awarded cash prizes as outlined in Table B – Awards and Funding and receive invitations to Stage 3: Live Evaluation. From the Best-in-Class Contests, the best performing team for each capability will receive respective Best-in-Class awards. NIST reserves the right to award non-cash prize invitations to contestants who are not in the top 10 Stage 2 winners or Best-in-Class Winners, but who pass Criterion 1 and receive a score on Criterion 2 above 30% of the total.”
No, we are going to provide a sensor that you can use for your testing. You will still have to create the drone piece and have some sort of command server that will collect data from the drone and retrieve the JSON files and photos. Ideally, you will be taking the photos from your drone and sharing them with the command server. If you have a specific sensor you created, please read the Stage 2 Guidance Document to ensure it aligns with the Stage 2 requirements. The cell phone is one of the use cases, but what we are trying to test here in Stage 2 is a simple method; we are primarily interested in the data-gathering aspect of this. That is correct, No cell phone signal detection will be evaluated in Stage 2/3.
The BOM is pass/fail, you may update it at any time in Stage 2
Yes! You are eligible to enter even if not selected in Stage 1.
For Stage 2, we are going to be using WiFi. If you use Lora, you can demonstrate that, but you will need to integrate WiFi into your solution in order to be evaluated. (see Stage 2 Guidance document for sensor and Github code). We will primarily being using WiFi in this challenge. We won’t be using cellular technology in this challenge. You can demonstrate another technology but you will be evaluated based on a WiFi system.
As stated in the Terms & Conditions of the Official Rules, “Individuals currently receiving NIST funding through a grant or cooperative agreement are eligible to compete but may not utilize the NIST funding for competing in this challenge.” Additionally, “Contestants may not be a NIST contractor or associate, or private entity providing services to NIST acting within the scope of their contract, employment, or funding or acquisition agreement with NIST which would involve the use of NIST funding to support a contestant’s participation in the challenge.”
Each entrant retains title and full ownership in and to their submission. Entrants expressly reserve all intellectual property rights not expressly granted under the Challenge agreement. By participating in the Challenge, each “contestant grants the Department of Commerce, National Institute of Standards and Technology, a royalty-free, non-exclusive, irrevocable, worldwide license to display publicly and use for promotional purposes the contestant’s entry (“demonstration license”). This demonstration license includes posting or linking to the contestant’s entry on the Department of Commerce, National Institute of Standards and Technology websites, including the competition website and inclusion of the contestant’s submission in any other media, worldwide.” Please refer to the Terms & Conditions in the Official Challenge Rules.
Please be aware that all cash prizes awarded to Participants by NIST are subject to tax liabilities, and no withholding will be assessed by NIST on behalf of the Participant claiming a cash prize. Please reference the Terms & Conditions in the Official Challenge Rules.
Any applicable intellectual property rights to a submission remain with the contestant. By submitting to this challenge, you do permit NIST certain limited rights. Please read the Submission Rights section within the Official Rules’ Terms and Conditions (beginning on page 25) and let us know if you have any clarifying questions regarding these limited rights.
We encourage contestants to read the rules thoroughly for each stage and make this decision accordingly.
Spectators will be limited to NIST staff, judges, Challenge contestant staff and media. Other spectators will be decided upon as we get closer to the date of the live event, and all spectators will be required to register in advance.
Contestants may write and edit submissions in LaTEX; however, we would request that Contestants send their final submission in .pdf or .docx format.
The cybersecurity requirement in UAS 6.0 focuses on a general understanding of the threats, implications, and mitigations of using Artificial Intelligence in UAS. This information can include connected systems, databases, user scenarios, etc. Remember that this deliverable is only required in the Stage 1 white paper, so proposals or solutions can be theoretical but must have plausible supporting evidence. This can be derived from original research, reputable sources, or similar/equivalent disciplines that aren’t necessarily UAS (e.g., self-driving cars) but must apply to first responder UAS. You may consider specific mitigation methodologies derived from cybersecurity privacy and security guidelines commonly utilized in enterprise and defense networks (e.g., DISA STIGs, NIST Cybersecurity and Privacy Reference Tool https://csrc.nist.gov/Projects/cprt, CISA, MITRE). The cybersecurity requirement does not have to be implemented in the solution in Stages 2 and 3.
The Official Rules notes that the paper should describe research/technology in a field that could be applied to and improve effective of a UAS in a public safety scenario such as those described in the Operational Use Case section. The key is the public safety use case. The paper could focus on one single component described on a micro level, but if your research covers a collection of components comprising a platform, we are certainly open to a paper describing more than one component. In this stage, we are not requiring the description of an entire UAS concept that will be then followed exactly when built in Stage 2. Our intention in Stage 1 is to incorporate new or existing UAS components while reducing the potential barrier of participation for an individual with research not currently applied to UAS, and who may either be overwhelmed with or not currently thinking about entering the UAS ecosystem. Regardless of what you choose to cover in your paper, we highly encourage you to thoroughly read Stage 1’s paper requirements and evaluation criteria in the Official Rules as well as the Stage 1 Guidance Document.
For Stage 1, contestants can submit something that solves a part of the problem that can be then integrated into a full UAS solution.
Please read the rules, specifically the evaluation criteria, and other resources available on the competition website. We are looking for concepts and ideas from all components that reside or may reside on a UAS and what risks they may impose to the drone operator. There has been little definition for public safety agencies or operators on steps to protect themselves from cyber and AI risks, so we would like your help in identifying what those risks are from the standpoint of your expertise.
To view the webinar recording, click here.
Absolutely. We encourage you to use this opportunity to publicly share your participation and any stage wins in the UAS Challenge. However, when publicizing your participation, you may not use NIST’s logo or official seal, and you may not claim NIST endorsement of your technology or organization.
NIST distributes prize money as a lump sum payment to the official team representative. NIST is not involved in any further distribution of prize money. The official team representative must be age 18 or older and a U.S. citizen or permanent resident of the United States or its territories.
Yes, as long as the team has at least one US citizen. Contestants are required to comply with the Eligibility Requirements outlined in the Official Rules.
There is no limit to the number of team members.
Per the Eligibility Requirements in the Official Challenge Rules, “At the time of entry, the Official Representative (individual or team lead, in the case of a group project) must be age 18 or older and a U.S. citizen or permanent resident of the United States or its territories. In the case of a private entity, the business shall be incorporated in and maintain a place of business in the United States or its territories.”
There is no limit to the amount of Public Safety Partners each team has. We encourage teams to explore whatever type and amount of partnerships they believe will best support their team in developing purpose-built solutions for the public safety end user.
We understand that there are always tradeoffs with various design choices and encourage contestants to try to optimize accordingly as best as possible. We also encourage contestants to form teams comprising a variety of expertise required or desired to develop a solution that best meets the competition criteria and public safety needs.
No. Both Stage 1 and Stage 2 are open to all eligible contestants. However, we encourage participation in both stages for more opportunity for solution feedback and to win challenge prizes.
That is correct. To enter, the Official Representative must be a U.S. Citizen. For more details, please refer to the Terms and Conditions section in the Official Rules on Challenge.gov.
Yes, Companies can register as well as individuals. More details can be found in the Official Rules.
The sensors or “cell phone” endpoints we are looking for in UAS 6.0 will utilize Wi-Fi as the protocol for detecting and transferring data from the sensor to the UAS. The idea in UAS 6.0 is to use radio mapping or signal strength tracking methodologies to locate and find a sensor in the field, transfer data from the sensor to the UAS, and then have the UAS deliver that data to a command server where it can be processed and/or viewed. This capability is possible with cellular and other wireless protocols; however, since Wi-Fi is well known to most, readily available, and has fewer regulatory restrictions, we decided to use it as the protocol of choice in this experiment. The scenario you mention in this case is a hypothetical use case to help visualize the potential uses of this technology beyond this competition. As for the transfer method between the UAS and the Command Server, you may use any communications method you see fit, including cellular. However, it is not recommended to depend entirely on cellular for this transmission since we are replicating a disaster scenario. The idea is for the UAS to “ferry” the data from the sensor back to the command server in a scenario where internet access is limited to a single Command Center or Mission Control area. In Stage 3, the Command Server may be deployed locally (near the pilot) with no or limited internet access. A Wi-Fi access point will be available to “deliver” the data to the command server.
In Stage 3, some sensors will be placed with Target Objects, such as NIST Open Test Lane bucket targets; however, others will be placed with objects and locations of interest or in areas with no reference. One of the goals in Stage 3 is to use radio mapping or signal tracking techniques to help find and locate sensors. Contestants and pilots should not completely depend on drone video, visual references, or “area sweeps” to find and locate sensors.
NIST will provide the Command Server. At the Stage 2 launch webinar, we will provide more information regarding the Command Server. After data collection, the UAS will be required to upload data to the Command Server. If you are currently testing this functionality, we recommend using a packet sniffer running on a PC or Mac, such as Wireshark, to serve as a temporary Command Server until more guidance is provided.
Yes, more to come on this after Stage 1; however, PSCR will utilize a COP platform to display and verify data. The specific format of the data that the platform accepts will be provided after Stage 1. For now, only consider that it will be delivered as an IP datagram using either TCP or UDP, likely the latter since most IoT data is delivered connectionless. Remember cybersecurity methods in this design as well, e.g., link encryption. For early Stage 1 development verification, a simple UDP server or packet sniffer can be used to verify data delivery.
For UAS 6.0, Wi-Fi will be the protocol used for data transfer mechanisms. Contestants should also consider methods for extracting metadata from the OCU, such as GPS, through an API or other mechanisms. This data will be used to “tag” the sensor location and may also be used in automated/autonomous path planning. Consider different networking methods, such as store-and-forward or forwarding data from the drone through the control link to the collection point. Either method requires Wi-Fi connections from the drone and/or OCU to the delivery point. Only ISM frequencies should be used (e.g., 915mHz, 2.4GHz or 5.8GHz) at no greater than the FCC regulated 1 Watt (30 dBm) limit. The 6GHz Wi-Fi frequency will not be used in the challenge since most IoT devices haven’t implemented 6GHz and power considerations. With plausible evidence, other frequencies may be used with proof of licensed operation (e.g., Ham operator license). This should be documented with your Stage 1 solution description.
For the Stage 1 white paper, contestants are not required to provide data; however, they should understand how IoT devices work, how data is transmitted and received, and how your solution may store and forward that data. IoT data devices and associated data should be specific to first responder scenarios. Contestants shall consider multiple sensor types, such as those from the PSCR CHARIoT Challenge. Dataset examples can be found at https://github.com/usnistgov/IoTData_EmergencyScenarios/.
Specific data sets and types will be provided later for the Stage 2 and 3 events. For Stage 1, we are looking for novel designs on how a UAS may serve as a data ferry that can optimally collect and serve IoT data. Examples of such a design may include networking device hardware choices, system diagrams, applications used for transmission and storage of data, etc. Be sure to include details or methodologies on how the UAS detects sensor signals.
For Stages 2 and 3, we are simulating a scenario where data is collected from IoT sensors on the ground versus actual, commercial sensors. The data will not be large streams of data, rather they will be small data files of less than 1Mbyte that may include imagery or simple data packets provided by ESP32 WiFi enabled IoT nodes. Prior to the launch of Stage 2, early to mid-August, we will provide a Stage 2 Guidance Document that will discuss the sample code we intend to provide all teams for you to include on your UAS for data collection from specialized radio equipment. The radios designed for Stages 2 and 3 will be represented by WiFi transmitters that are easy and legal for teams to procure, build, and operate. To further understand the Stage 2 design, a team that specializes in radio mapping or path planning is not locked out of the competition because they don’t have expertise in, say, the radios necessary to simulate and decode 4G cellphone transmissions.
One of the scenarios is search and rescue mission, and locating phones can be assumed. Overall, the data collection will focus on collecting data packets that simulate IoT devices including phones. We will not ask competitors to communicate with trapped people or send SMS to the phones. This could be demonstrated by a team but is not required per Official Rules criteria.
We are not focused on collecting data from rogue drones; rather, we will collect data from sensors on the ground for delivery back to a central location. This question could be discussed in a stage 1 paper but is not a part of Stage 2 and Stage 3.
Yes, within the hydroplant scenario, a UAS would access data from sensors already existing within and around the hydroplant. Note that Stage 2 will include simulations of sensors for UAS to locate, extract, and deliver data.
Each public safety agency has unique needs or uses cases. Please listen to the webinar recording (timestamp 20:25) for a firsthand view from the guest first responder, and reach out to public safety members in your local community for more ideas or user testing. One example given is to use AI and the UAS camera in a mass casualty scenario to find the safe routes in and out of the incident area. Also, AI and IoT sensors could help identify evacuation sites and the flow of people in and out of the area for better occupancy capacity planning.
There is not a preference for IoT hardware. Note that there are a number of different sensor types included in the public safety scenarios in the Official Rules’ Operational Use Case section.
Relying entirely on the public cellular network(s) for this communication is not recommended. The idea is for the UAS to “ferry” the data from the sensor back to the command server in a scenario where internet access is limited. To put this in perspective, think about a wildfire in a canyon in Colorado. Many of these places have degraded or non-existent communications infrastructure. A command vehicle at the bottom of the canyon may have a Starlink satellite providing internet connectivity to a command server in the cloud. In this scenario, we would use a drone to collect sensor data further up the canyon and ferry it back to the command center. We are focusing on the plausibility of using the UAS as the data relay where internet connectivity and other resources to support network connections may not be available.
In Stage 2, contestants will build performance/measurement apparatuses, data sensors, collectors, and delivery mechanisms for their solutions. The performance aspect is primarily used to evaluate how long the UAS can endure in one battery cycle. This factor will ultimately determine how many data points the system can collect before returning to the data delivery point. Stage 3 will follow a similar evaluation method; however, this will be at a live evaluation event, and the number of sensors and search area will be much larger. The sensors, data types, and delivery verification mechanisms for Stage 2 will be provided after Stage 1.
The cybersecurity requirement does not have to be implemented in the solution in Stages 2 and 3. For your architecture design or Stage 1 description, you may consider hardware, software, or systems solutions with hardening mechanisms, such as encryption (storage or in-transit), authentication, identity verification systems (of the drone, pilot interfaces, and delivery points), or malware and intrusion detection. While many of these methodologies are implemented by default in many UAS solutions, bringing awareness and understanding of these features to potential users is important. Conceptualize yourself as a consultant or salesperson, describing how cybersecurity is used in your solution for a potential first responder customer. Think of how you can reassure them that your solution is secure. Consider how it remains secure after the sale with ongoing solution maintenance.
We understand that, in practice, emergency responders may fly multiple drones on a mission; however, for the challenge, we want to simplify the focus on developing innovative components of the UAS to meet the use case and its capabilities. Based on the UAS Required Specifications and Metrics outlined in the Official Rules, we believe the task of collecting and distributing the data will be challenging for one UAS given the design tradeoffs. Things break, so you can plan for backup components in Stage 3, as appropriate. For the Stage 1 research paper, you can discuss any UAS component or novel approach to ‘wirelessly data gathering’ in an outdoor environment, including risks of any such components to public safety, within your concept. You can submit what you believe solves ALL Stage 1 evaluation criteria in your Component research paper – we encourage you to read the Rules and supporting documentation on the website. With regards to flying multiple drones in Stages 2 and 3, this would not be compliant.
Depending on the application, some tasks, like surveying a large area, can be performed autonomously with the pilot out of the loop, making it a truly autonomous mission. This can be enhanced by incorporating AI for further guidance, data collection, and data harvesting. There are two main approaches: one involves having a pilot in command with a payload specialist running the application, while the other is fully autonomous. Both solutions should be available as options. For example, many nighttime flights to survey wildfires can be entirely autonomous, with the pilot intervening only when necessary. Automating these processes and removing the human from the loop can often be beneficial.
While this is not required within this competition, we do encourage contestants to consider selecting/developing components and solutions that are Blue/Green capable.
Yes, we are looking for component technologies residing on a drone, including but not limited to the examples noted in the question. However, be aware that Stage 1 is to help us understand what the risks are for cybersecurity and AI within a solution. We would like to see contestants’ solutions then operate in Stage 2.
We are attempting to focus our research on expanding the UAS technology, so autonomous flight might be an advantage. Flight will be timed, and contestants will need to collect as much as data as possible and deliver it with usability and clarity. Please review the specifications table and judge scoring for more information.
Contestants should design their UAS solutions to fly in both urban and rural areas as first responders operate in both. We encourage contestants to refer to the scenarios detailed in the Official Rules’ Operational Use Case section.
No. System designs can utilize commercially available products in their design.
You are free to design your UAS as you like. However, the NIST logo cannot be included.
Insurance is highly encouraged throughout entire competition but not required until a team submits in Stage 2.
Yes. The goal is to develop an innovative solution for first responder teams, which can include work you developed prior to this competition. However, submissions must adhere to specifications detailed in the Official Rules.
Yes. Updates to proposals can be submitted until the proposal deadline. Only the latest version will be evaluated.
No. Each unique team or Contestant may submit one proposal.
No, that is not necessary. However, we do encourage you to sign up on the Challenge website (firstresponderuas.org) to receive updates about the Challenge.