---
# System prepended metadata

title: Notes on my first week on the asimov team

---

# First week in Asimov team

- Simulation project has as dependancy the data engine in order to create an environment based on the robots data and vice-versa, perhaps we are 1-2 months 
- Daniel is considering the use of digital twins, especially for self-driving applications.
- Digital twins are a key goal for simulating and improving robot-environment interactions.
- Current robotics work is labor-intensive, particularly in physical interaction with the environment, providing a simulated version of a physical could help us drive momentum and adoption once we open the monorepo
- Locomotion does not require highly accurate environments but needs robust physics and joint dynamics simulation (e.g., using Mujoco).
- Data Engine collects and stores data from robots (lidar, sensors, positions) for visualization and further use.
- Human movement data can be processed and transferred to robots via the data engine. I related this to concept of rotoscoping in the animation and film industry that I mentioned during my chat with Ron
- Simulation efforts are focused on locomotion at the moment
- Emphasis should be on understanding how each system component works together from the robot to the simulated environment and back
- We are considering using AI models to handle and follow movement, though this approach is still under evaluation and could require a lot of cash on cloud compute
- Exploring ways to enable continuous learning and stay updated on current research trends. There were two approached in recent years, one is called river and it is more for traditional ML and the other is called avalanche and it is based on PyTorch
- Selim mention we could strive polish the idea that we're building the "Ikea for robots" where users connect to a cloud-based data engine, with hardware as a means to access software. They can assemble each component and fix it if it breaks through instructions via our UI
- Focus on maximizing software capabilities and minimizing hardware dependency (e.g., 3D printed parts, easy replacement, can we do the same fo rrobots?
- In Asimov, robots are sold cheaply, possibly open-source, to drive distribution
- Marketing is a bit of a challenge as these robots, however low cost, can be quite expensive). Positioning robots as an alternative to popular consumer electronics (e.g., PS5 or XBOX) could be viable if costs gets reduced drastically without impacting quality
- 3D printed parts can be self-printed or purchased at a small markup
- Software is offered as a free SaaS product; initial focus is on distribution and assembling documentation
- Long-term vision includes selling cloud services, intellectual property, hardware
- **Aspiration for a "ChatGPT moment" in robotics, where software capabilities dramatically improve the usage of personal or company robot**
- Vision for Asimov includes easy assembly (screwdriver, instructional videos), community support (Discord), and affordable pricing (under $10k).
- Robots will have an API for coding, developer mode, and factory reset options. My worry is how do we avoid building too many layers of astraction and keep the spaghetti straighten
- Proprietary models for vision, speech, and text, with training available on the cloud. Perhaps this takes ideas from the fine-tuning service of the cloud
- Ability to search and replay specific robot experiences via text queries, similar to app debugging tools like sentry an posthog but for the robot in the simulated env
- Focus on the simplest possible robot embodiment to maximize accessibility and utility
- Add support for new or existing robots as quickly as possible