Comparison to alternatives¶
j5 was designed to supersede a number of similar libraries. The table below gives a brief comparison between j5, robot-api / robotd and sr.robot.
|Feature||j5||robot-api / robotd||sr.robot|
|Cross-Platform Support||Yes||No (Requires Linux + udev + systemd)||No (Requires Linux + udev)|
|Custom / Game Logic without core changes||N/A||No||No|
|Explanative error messages||Yes||No (Pipe Error)||Mostly|
|Advanced Fiducial Marker Support||Yes (Zoloto)||Partial (sb-vision)||Yes (Libkoki)|
|Run code without hardware||Yes (ConsoleEnvironment)||No||No|
|Supports multiple environments / backends||Yes||Yes||No|
|Supports SourceBots Servo Board||Partial||Yes||No|
|Supports SR v4 Kit||Yes||Partial Support||Yes|
|Test Coverage||> 98%||Some||No|
|User Documentation||N / A||Yes||Yes|
Robot Operating System (ROS)¶
The Robot Operating System (ROS) is a flexible framework for writing robot software. It is a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behavior across a wide variety of robotic platforms.
The brief paragraph above makes it sound like ROS is very similar to j5 and the basic idea behind it is. However, j5 is more suitable for students due to the following:
- Hardware implementation is Python, easier to understand / debug than C++.
- Standard libraries can be used in student code to add custom hardware in j5, i.e from Adafruit.
- Smaller codebase.
- Simpler architecture.
- ROS is a real-time operating system, which presents a different way of programming than most students will have been taught.
- ROS is aimed at research environments, j5 is aimed specifically for robotics competitions.
- ROS is complex - The ROS framework is a multi-server distributed computing environment allowing software applications to communicate across server boundaries and thereby acting as one software system. - We do not need distributed computing. - The more complicated the system, the harder it is to debug. We want to allow students to debug their code.
- ROS does not expose a common API for various hardware. Instead, the appropriate messages must be published to that hardware, which will be different.
- ROS does not have a security model.
- ROS has no automated system for upgrading firmware, nor for updating itself.
- ROS has no configuration management system.
- The ROS messaging system has a fairly large overhead.
- It is non-trivial to add extra hardware support in ROS, raising the barrier to students using non-provided components.