| SDK | Check API coverage, sensor and actuator access, version policy, examples and whether the SDK works offline. | Look for a stable, documented SDK with maintained examples that staff can pin for a semester. | Prefer a supported classroom API or visual toolkit with clear teacher documentation and recovery steps. |
|---|
| ROS support | Confirm the ROS and ROS 2 distributions, maintained packages, source availability and supported bridges. | Match ROS support to the syllabus and confirm the supplied image works on managed lab machines. | Do not treat ROS as a default requirement. Confirm whether it is optional and appropriate for the course level. |
|---|
| Programmability | Check supported languages, root or container access, onboard and offboard compute, simulation and deployment restrictions. | Check languages, debugging tools, simulation and whether student projects can be reset and assessed consistently. | Look for a progression from visual programming to text code, with permissions that limit changes to the intended classroom activities. |
|---|
| Configuration | Confirm which sensors, end effectors, compute modules and firmware can be changed without voiding support. | Prefer identical fleet configurations, repeatable imaging, available spares and a documented reset process. | Prioritise a complete kit, documented defaults, simple charging and storage, and minimal setup before each lesson. |
|---|
| Licensing | Read the terms for source modification, publication, redistribution, commercial follow-on work, cloud use and research data. | Compare campus, lab, per-seat and per-device terms, including course-material redistribution and annual fees. | Check student-account rules, data handling, curriculum licences, cloud subscriptions and renewal pricing. |
|---|