> For the complete documentation index, see [llms.txt](https://x.ancorasir.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://x.ancorasir.com/bionicdl/teaching/rob7103-8103-embodied-ai-systems-mbzuai.md).

# \[ROB7103/8103] Embodied AI Systems @ MBZUAI

## Course Description

This seven-week course examines how AI methods become parts of measurable, reproducible, and responsibly operated physical systems. It assumes prior competence in machine learning, computer vision, reinforcement learning, and related AI methods. It does not repeat general AI, kinematics, control, or planning courses. Instead, it concentrates on embodiment, sensing, actuation, communication, calibration, fabrication, simulation, Sim2Real evidence, robot-learning deployment, and experimental diagnosis.

The course normally contains three scheduled events per week, with durations determined by the official timetable. It includes six linked Embodied AI Meets Design worksheets, one revised worksheet portfolio, and one team final project. The optional two-day Seeed hackathon is a separate supervised event; its reference manuals are included because they also support independent study and later research use.

The course begins on October 20, 2026. Access to the supporting source repositories is managed separately and does not determine the copyright or licensing status of the rendered materials.

## Learning Outcomes

By the end of the course, a successful student should be able to:

1. Define and critique an embodied-AI system. 
2. Engineer and bring a physical–digital platform into operation. 
3. Produce research-quality embodied experience. 
4. Evaluate correspondence between computational and physical representations. 
5. Assess learning inside a real robotic feedback cycle. 
6. Deliver and defend a repeatable team prototype. 

## Course Instructor & Teaching Support <a href="#course-instructors-teaching-support" id="course-instructors-teaching-support"></a>

* **Lead Instructor**: Dr. Chaoyang Song (Chaoyang.Song\[at]mbzuai.ac.ae)
  * **Office Location**: C-1.01
  * **Office Hours**: 1000\~1200 on Mondays
* **Teaching Assistant 1**: Dunxing Zhang (Dunxing.Zhang\[at]mbzuai.ac.ae)
* **Teaching Assistant 2**: Hang Yang (Hang.Yang\[at]mbzuai.ac.ae)
* **Technical Support 1**: Dr. Mohamed Halwani (Mohamed.Halwani\[at]mbzuai.ac.e)
* **Technical Support 2**: Jinqi Wei (Jinqi.Wei\[at]mbzuai.ac.ae)
* **Technical Support 3**: TBD (XXX)
* **Course Consultant**: Dr. Fang Wan (wanf\[at]sustech.edu.cn)

## Grading Policy

Assessment combines individual participation with a progressive team project.

<table data-header-hidden><thead><tr><th width="462.265625">Assessed component</th><th>Basis</th><th>Weight</th></tr></thead><tbody><tr><td>Recorded attendance across scheduled meetings</td><td>Individual</td><td>10%</td></tr><tr><td>Six staged project records</td><td>Team</td><td>30%</td></tr><tr><td>Consolidated and updated project record</td><td>Team</td><td>10%</td></tr><tr><td>Working system and reproducibility package</td><td>Team</td><td>25%</td></tr><tr><td>Technical poster</td><td>Team</td><td>5%</td></tr><tr><td>Narrated project video</td><td>Team</td><td>10%</td></tr><tr><td>Oral briefing and response to questions</td><td>Team</td><td>10%</td></tr><tr><td><strong>Total</strong></td><td></td><td><strong>100%</strong></td></tr></tbody></table>

### Assessment principles

* The six staged records are worth 5% each. They document the development of the project claim, system design, data, evaluation approach, findings, constraints, and next action.
* The consolidated record should show how the project changed in response to tests and feedback. Revision is judged by the quality of reasoning and evidence, not by visual refinement alone.
* The prototype grade covers the prepared robotic system as well as the code, configuration information, dependencies, calibration records, and instructions needed to repeat the supported result.
* The final communication components should accurately distinguish demonstrated findings from assumptions, aspirations, and unsupported uses.
* When physical execution is unsafe, or equipment becomes unavailable, an alternative based on simulation, replay, recorded evidence, or another approved method may be used only with prior instructor authorization.
* Moodle contains the controlling assessment briefs, rubrics, submission locations, due times, and any approved changes. If this page and Moodle differ, seek clarification before the deadline.

Although most marks arise from team submissions, every student must be able to explain their own work and the team's key technical choices. Assessment briefs may require contribution records, repository history, short individual checks, or similar evidence of participation. Any procedure that can change an individual's mark will be stated in writing before it is applied.

Late work, extensions, approved absences, reassessment, and grade-review requests follow University rules and the instructions released for the relevant task. Students should not assume an equipment problem automatically extends a deadline; report issues as soon as they arise.

## Academic Integrity

All work must comply with the University's academic-integrity requirements and with the specific collaboration and tool-use conditions stated for each assessment. Because this course depends on shared code, research papers, datasets, pretrained models, CAD files, and external software, clear attribution and traceability are essential parts of scholarly practice.

Students are expected to:

* cite publications, documentation, datasets, software, models, hardware designs, media, and other reused material;
* preserve license notices and observe any restrictions attached to third-party resources;
* distinguish their own contribution from instructor-provided, teammate-produced, open-source, and machine-generated material;
* maintain authentic experiment records, including unsuccessful trials and relevant changes to hardware, code, parameters, or data;
* verify technical claims and inspect generated code or text before including it in assessed work;
* disclose the use of generative-AI or automated coding tools when an assessment brief requires it; and
* retain sufficient development history to explain how the submitted result was produced.

Examples of unacceptable practice include inventing or altering measurements, hiding failed runs that materially affect a conclusion, presenting another person's work as one's own, submitting unverified machine-generated content, disguising the source of reused assets, sharing restricted assessment material, or bypassing safety and authorization controls to obtain a result.

## University Calendar

TBD

## Lecture & Lab Notes

<table><thead><tr><th width="108.9375">Class</th><th width="173.0625">Date and Time</th><th width="83.83203125">Location</th><th width="376">Content</th></tr></thead><tbody><tr><td>01</td><td>Oct 20, 0900–1020</td><td>CR6</td><td>Course Introduction and Team Formation</td></tr><tr><td>02</td><td>Oct 21, 1030–1150</td><td>CR6</td><td>1-DOF System Design and Prototyping</td></tr><tr><td>03</td><td>Oct 23, 0900–1050</td><td>L12</td><td>System Assembly, Calibration, and Motor Data</td></tr><tr><td>04</td><td>Oct 27, 0900–1020</td><td>CR6</td><td>Learned Disturbance Recovery and Sim2Real Validation</td></tr><tr><td>05</td><td>Oct 28, 1030–1150</td><td>CR6</td><td>Multi-Motor Communication and Actuator Modeling</td></tr><tr><td>06</td><td>Oct 30, 0900–1050</td><td>L12</td><td>LEAP Hand Assembly, Fabrication, and Simulation</td></tr><tr><td>07</td><td>Nov 3, 0900–1020</td><td>CR6</td><td>In-Hand Robot Learning and Sim2Real Deployment</td></tr><tr><td>08</td><td>Nov 4, 1030–1150</td><td>CR6</td><td>Multimodal Robot Perception on the Mobile Edge</td></tr><tr><td>09</td><td>Nov 6, 0900–1050</td><td>L12</td><td>Hand Motion Retargeting and Demonstration Data</td></tr><tr><td>10</td><td>Nov 10, 0900–1020</td><td>CR6</td><td>Vision-Guided In-Hand Manipulation</td></tr><tr><td>11</td><td>Nov 11, 1030–1150</td><td>CR6</td><td>Worksheet 1 and A Simple Arm I</td></tr><tr><td>12</td><td>Nov 13, 0900–1050</td><td>L12</td><td>Worksheet 2 and A Simple Arm II</td></tr><tr><td>Hackathon Day 1</td><td>Nov 14, 0900–1700</td><td>TBD</td><td>Optional Supervised reBot Hackathon Day 1</td></tr><tr><td>Hackathon Day 2</td><td>Nov 15, 0900–1700</td><td>TBD</td><td>Optional Supervised reBot Hackathon Day 2</td></tr><tr><td>13</td><td>Nov 17, 0900–1020</td><td>CR6</td><td>Worksheet 3 and Final Project Preparation I</td></tr><tr><td>14</td><td>Nov 18, 1030–1150</td><td>CR6</td><td>Worksheet 4 and Final Project Preparation II</td></tr><tr><td>15</td><td>Nov 20, 0900–1050</td><td>L12</td><td>Worksheet 5 and Final Project Preparation III</td></tr><tr><td>16</td><td>Nov 24, 0900–1020</td><td>CR6</td><td>Final Project Integration and Preparation IV</td></tr><tr><td>17</td><td>Nov 25, 1030–1150</td><td>CR6</td><td>Worksheet 6 and Final Project Preparation V</td></tr><tr><td>18</td><td>Nov 27, 0900–1050</td><td>L12</td><td>Final Poster Submission and Final Project Preparation VI</td></tr><tr><td>19</td><td>Dec 1</td><td>Public Holiday</td><td>Final Code Submission and Final Project Preparation VII</td></tr><tr><td>20</td><td>Dec 2</td><td>Public Holiday</td><td>Final Video Submission and Final Project Preparation VII</td></tr><tr><td>21</td><td>Dec 4, 0900–1050</td><td>L12</td><td>Final Project Showcase</td></tr></tbody></table>

### Optional Events

The two-day Seeed Studio hackathon is a separate optional supervised activity. It may include assembly, first-time commissioning, teleoperation data collection, training, and student deployment that are intentionally excluded from the regular Class 11 and Class 12 hands-on scope. We are not sure whether such an arrangement is operational at MBZUAI or not yet.

## Student Team and Group Formation

TBD


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://x.ancorasir.com/bionicdl/teaching/rob7103-8103-embodied-ai-systems-mbzuai.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.