“ One word is the entrance, and engineering is still the door.
The 3D printer stops, the finished product is still on the platform. People don't get up, the next round of printing can't start; the upkeep process, the whole night's sleep is cut in two. On the way, the electric cat litter box is stuck, friends can only drive to the door.
These problems are not huge, but they are specific enough. They are also the most real starting point for the Star-Dust OS robot hackers. On October 24-25, the Star-Dust OS Robot Hackers Final, hosted by Star-Dust Intelligent, will be held in Shenzhen.
It was reported that the three stations had a total of 47 teams participating in the tournament, 17 teams in the overall finals completed development and real-time debugging in 36 hours, 16 app run-through real-time machines, with a real-time probability of about 94%. A bunch of not all creators from a robotic engineering background, using the Astribot intelligent robot operating system (AOS) to run the link between demand, capabilities, simulation and real-time machines.
The robotics workshop interviewed engineers related to StarDust intelligence to discuss the latest developments in StarDust AOS.
01.
To pack complexity into modules, what exactly is AOS?
In the interview, the definition of AOS was clear: a robotic perception, movement, operation, interaction packaged into call-ability modules, and aimed at AI and human-designed, physically applied operating systems.
This definition has several key words: first is encapsulation. Developers do not need to write underlying controls, communications and hardware drives from scratch, so that they can directly call on a meta capability package such as visual recognition, crawling, moving, voice, graphics transmission. Second is dual design. Interfaces are designed to make people understand and make models read, allowing models such as GPT-6, DeepSeek, and Claude Code to understand, call, and combine robot capabilities. Third is the operating system. It not only manages a single action, but also organizes tasks, coordinates capabilities, and connects simulation to reality.
To put it bluntly, AOS is close to the application development platform, the capability to call a toolchain, the combination of a robot's App Store and AI model to position itself beyond a single software tool.
In the interviews, Star Dust repeatedly mentioned DFAI (Design for AI, AI-oriented design), which we think is the most unique point here.
DFAI allows developers to allow models to read interfaces, call capabilities, and organizational tasks at the beginning of the design; traditional robot superimposed AI practices are difficult to support this link. Under DFAI's path, models are responsible for understanding and planning, AOS is responsible for organizing and scheduling, and rope drivers are responsible for execution and feedback in the real world. All three form a chain.
AOS wants to put complexity into the platform and leave the simplicity to the creator. Complexity will not disappear, it will be redistributed between the platform and the developer. The value of the platform is that most developers do not have to stack the same complexity over and over again.
Speaking of the differences between robotic platforms such as AOS andROS, AOS strongly binds AI, interfaces both servers and service models, allowing models to understand, call and combine robotic capabilities. At the same time, AOS will not be limited to the AOS kernel, the goal is an open platform; security, permissions and data closures are managed by AOS unified, covering model calls, kernel controls, simulation deployments and the entire chain.
02.
What's going on with the 36-hour flight?
In the field, many applications are based on AOS development, and the Robotics Workshop found that the current developer threshold remains, with some developers with development experience being the easiest to master; product managers, designers, kindergarten teachers, etc. are the most versatile background creators; traditional industry practitioners without a software background are the hardest to learn and need to collaborate with AI Agents. This means that the threshold has shifted to a higher level, with AOS moving from the very bottom of iterative development, leaving needs judgments, abnormal design and experience to the people, allowing developers to make scenic needs a reality.
For example, the championship project is remote separated, people go out, and the other stays at home. In 36 hours, the team turns on the dual-directional real-time control link between the mobile phone and the robot, connecting the graphics, crawling, voice, mobile dashboard and operating capabilities into one link, completing tasks such as catching sand, picking up flowers, pouring water, courier, chatting, etc.
In the process of developing the project, AOS provided an easier-to-use developer toolchain with corresponding interfaces from query, development to debugging and deployment. They also built a general architecture that could be further expanded into home security or travel management in the future.
The inspiration for CatDance travel cat managers came from a trip: the electric cat sandbox is stuck at home, and friends can only drive up the door to process it. The team develops applications for tasks such as watching cat sand while away from home, as well as pushing AOS to optimize remote control and state feedback interfaces.
The undefined 3D printing feed application of the team, stuck to the finished printing feed link: the robot takes the finished product, puts back the printing board and starts the next round, with the goal of reducing human midnight watch. This direction also promotes improved grip accuracy and abnormal processing capabilities. It is less transmissible than the writing code of a humanoid robot, but closer to the real production process: the equipment is half-automated, the remaining few steps still need to be followed, and robots are following these steps.
The book's application asks Mer to bring the twin brothers into the contest from a younger perspective to write their memories of springtime;
The follow-up project attempts to get the robot to lock and move Osmo Pocket as a person and follow-up;
Projects such as chess, photography explore face-to-face interaction and photographic creation; the first two stations also feature DJ choreography, accompanying reminders, and table tennis.
Putting these cases together, we can see one thing in common, which is that demand comes from the creators' observations of real life and work, and the list of functionalities set by manufacturers does not cover these gaps. What AOS does is actually turn demand into a threshold for demonstrable applications.
From the results of the competition, AOS initially confirmed one thing: a team with no experience in robot development can also call packaging capabilities in a limited amount of time, complete a simulated link to a real machine. Compared to some hackers, a 94% chance of being real is a positive signal.
03.
One word is the entrance, and engineering is still the door.
It is worth noting that in this competition, many developers on the ground worked together to develop robotic apps, directly summon complex robotic capabilities, from simulation to real-time rapid verification, to design for humans for AI, and to collaborate with models such as GPT-6/Claude Code.
In the interview, StarDust also clarified the principles and boundaries. In fact, the real path to generating these apps is: natural language requirements→ AI dismantling tasks→ calling AOS capabilities/SDK→ simulation testing→ real machine verification.
In other words, it's more about input and interaction, and there's still a long way to go from complete automation. AOS reduces the underlying drives, communications, controls, simulation environments, and re-developments; real-world object gestures, forces, abnormalities, and task details that developers themselves have to go through.
Running machines are not the same as product availability. Robot applications also face security, real-time, hardware fragmentation and long-tail abnormalities; AOS is still in a period of rapid decline, third-party hardware compatibility has not been fully opened, and mechanisms such as application distribution, billing, and developer support require time verification.
04.
How open will AOS be?
As of the interview, the following AOS eco-opening strategies we have outlined are as follows:
SDK: Open to research and commercial users;
Documentation: Wiki documentation is continuously improved;
Simulation environments: providing mock machines and simulators;
Real machine quotas: Hackers and partners prioritize;
Developers' Plan: Launched, with training and activities;
Fees: Hardware fees, software modules fees;
Open source: not yet open source;
Third-party hardware compatibility: not yet fully open as planned.
While hardware compatibility is not yet fully open, application distribution, billing, and developer feedback mechanisms are still in their infancy, plans for future developer certification, training systems, and community operations are in the planning stages; excellent teams can enter partner programs, and those who intend to do internships or work for the company.
Because the ecosystem doesn't grow naturally with the release of tools. Developers come to see if it can stay; applications are made, and if they can be used, distributed, or paid for. AOS is out of PPT, and the future is to continue to build richer toolkits and premium apps that will eventually enter the App Store.
Over the next year, these eco-success verifiable indicators, including the number of active developers, the number of apps, the running time of real machines, the number of commercial orders, and the number of secondary developers, are more realistic than the analogue of the robot-era iOS. They correspond to whether developers are willing to come, whether applications are willing to come, whether robots are willing to run, whether businesses are willing to turn around, whether others are willing to develop on the platform twice.
Because like Apple's walled city, not only on the iPhone, but also where developers can make money, users are willing to use it, the system is stable enough. Robots are more of a physical world than a phone, security, real-time, hardware fragmentation, long tail anomalies, and anything that can make an application appear to be undeliverable.
While a hacker may not be able to prove that the robot app ecosystem is already established, it at least pushes the issue one step further, from what robots can do to who can create new uses for robots.
The answer to the first question is in the hands of the manufacturer, and the answer to the second question is probably in the hands of more developers.