Comparison to alternatives

Similar Libraries

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

Developer Documentation

Yes

No

No

Explanative error messages

Yes

No (Pipe Error)

Mostly

Advanced Fiducial Marker Support

Yes (Zoloto)

Partial (sb-vision)

Yes (Libkoki)

OSI Licence

Yes

Yes

No

PEP8 Compliant

Yes

Non-strict

No

PyPI

Yes

No

No

Python 3

Yes

Yes

No

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

Type Checking

Yes

Partial

No

User Documentation

N / A

Yes

Yes

Versioning

Yes (SemVer)

Yes

No

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.