Challenge Sponsor: Army

• Tag2Target: Develop COTS Beacons modified from Air Tags to allow non apple devices to communicate, pass PLI data in COT format.
• Electronic Flashbang: Current USASOC flashbangs cause significant amount of smoke by design that when used during Close Quarters Battle (CQB) create a situation where Soldiers have to wait for the smoke to clear and lose the advantage of surprise. These munitions also present a high probability of setting targets on fire, as well as causing injury to non-combatants and role players during realistic training scenarios. An Electronic flashbang with similar performance to the current devices would give the Soldier the same advantage of surprise and disorientation while reducing the need to slow down CQB in order for smoke to clear.
• Automated low-cost non-GEO satellite tracking system: Most small Ku-Ka band antennas are not motorized for automatic tracking of non-GEO satellites. There are several satellites of interest, think university cubesats, moving too fast to downlink with small portable antennas that are easily deployable. Larger antennas are prohibitively costly and large to relocate to areas of interest. A low-cost tracking head, similar to one that might have been used to track the recent solar eclipse with a telescope, could allow these types of antennas to track a known object in a lower orbit. Develop a low-cost tracking head using off the shelf parts, 3-D printed parts, or a combination there of, that can be attached to the top of a tripod or similar mobile mount and reliably point a commercial 10kg panel antenna at a fast-moving orbiting object. This design should be able to be manufactured, assembled, and operated by a non-expert with moderate technical and mechanical knowledge.
• Hiding in the Noise: Military formations are loud (on the electromagnetic spectrum) when they operate. How can we dampen that noise where our formations are and create that noise where our formations are not?
• Digital ID: As privacy technologies on devices get more and more effective (i.e. the rise of MAC Randomization), our ability to understand who is who across networks is degraded. What are some processes, tools, or systems that could be used to increase our understanding of the signal environment?

Challenge Sponsor: Navy

• Wire-free comms/data/power accessories: current solutions must be wired because of risk considerations of “stray” transmitting. The operator becomes a “spaghetti dinner” of wires and cables, especially Joint Terminal Attack Controllers. Having very low RF transmit power with low size/weight/power needs for each commodity, seems to be “the way” to get after it, but open to innovative and assured solutions.
• Smaller form factor/innovative MIO embarkation/scaling implements: ship boarding and other maritime interdiction operations (MIO) have relied on ladders of different forms, sizes, and structures. Since time and memoriam, VBSS parties have always used ladders. Are there other low-risk/innovative solutions for a squad of operators to scale the hull of a ship safely, including their equipment (40-80 lbs)?
• Small form factor, non-munitions-based MIO breaching implements: MIO squads have always used some form of a saw, torching, or pneumatic implement in order to access rooms and hatches on target vessels. These implements aren’t much different than those of Fire Departments, to be honest. They are bulky, and at many times have to be hoisted up after the squad has embarked the vessel. Are there smaller or innovative methods of breaching access points without the usage of munitions and charges?
• Digitizing Combat Capability Evaluation Process: Current combat evaluation processes are done through emailing proposals to a review team that then manually reviews for high level safety issues and relevance to current requirements. This process takes a long time to process just one proposal. NSWC would like to digitize the process by building out a module in SOFRRAS, which is a requirements generation software that was developed in house. A cadet currently interning at NSWC is conducting analysis and interact with all key players to generate a Plan of Action & Milestones during his internship relative to the potential implementation of a digital solution. The main objective of this challenge is to leverage the information collected by the intern and conduct follow up interactions with NSWC personnel to develop an appropriate digitized process for combat capability evaluation.
• Generative-AI for SOF Writing: Develop an AI tool that can aide SOF personnel with basic but time-consuming tasks such as writing awards, contracts, statements of work for training, … with a data base where personnel can ask LMs to integrate policy, legal doctrine, and supporting references

Challenge Sponsor: Joint

• Multi-Drone Control and Automated End-Game: Current drone usage involve an operator dedicated to each drone. How can we enable a single operator to control a drone swarm in contested / denied operations? Consider means to enable range extension, collaborative tasking, and automated end-game.
• Autonomous Surface Vessel Kit: How can you transform everyday consumer surface vessels / watercrafts into autonomous uncrewed surface systems capable of carrying goods over long distances. .
• Develop an Offensive Cyber Operations focused Large Language Model: Concept of operational usage: A military cyber capabilities developer logs into non-internet facing development machine. The developer launches Ollama with custom LLM. The developer integrates their development process with LLM using plugins to Visual Studio Code or Open Web GUI. The developer has access to fine-tuned support in the form of chat or code-completion with the LLM.
• Code Once – Run Anywhere: Can you apply oneAPI to a specific app, porting it to multiple xPUs. This would prove utility of “code once – run anywhere paradigm”. See oneAPI Programming Model. USAI will have multiple apps (e.g., collaborative autonomy logic (probably in the form of an intelligent agent)) running on the Autonomy Platform as well as AI models that will need to run on various UxS. Some may have GPU resources available but all should have CPU (but still may be different CPU architecture such as RISC vs. ARM vs. AMD-64). Some might even have FPGA resources available. Effort should evaluate performance of code ported via oneAPI to code written for the architecture (e.g., Verilog or VHDL for the FPGA).