A Roadmap

[nmccrea]

I recently had the opportunity to come back to this project after many years and perform some critical maintenance, with the much-appreciated help of contributors. The project was ported from Python 2 to Python 3, the documentation was updated, and the entire codebase was linted to adhere more closely to standard Python style guidelines.

I also identified the next steps that I believe should be taken if this project is to keep evolving. The motivation for these tasks is to make Sobot Rimulator more portable and accessible, easier to extend and maintain, and more generally useful for education, research, and development of 2D autonomous robot control and navigation systems.

This issue is here to document the tasks I think should be tackled next, along with some more ambitious ideas that appear towards the bottom. These tasks are as follows:

More Critical Maintenance

These urgent tasks are focussed on bringing the project up date with minimal best practices for modern software development.

• [ ] Replace GTK

  GTK is making a lot of things more complicated than they need to be since it is not a Python library. There are many alternative widget libraries that are platform-agnostic and can be installed with pip alone. I'm frankly a little overwhelmed by the choices, but I would probably try out Kivy first, since it seems to have good cross-platform support and a robust and active community. Other GUI libraries should be considered as well. I think the primary goal should be to maximize the software's portability and ease of installing and running.

• [ ] Implement comprehensive dependency management within an isolated environment

  This should use something like Pipenv or Poetry. Currently GTK is kind of obviating the usefulness of this, so once it's gone this can be properly addressed.

Maintainability

These tasks are aimed at making it easier to work with and evolve this codebase responsibly as time goes on.

• [ ] Fix remaining black and flake8 linting failures

  This is currently blocked by GTK, as noted here. Once the GitHub action for linting passes with no errors, it can be enforced for future pull requests, thus helping keep the codebase clean and healthy.

• [ ] Replace code that is better handled by external libraries

  When I originally built this project, I thought it would be a good learning experience to implement all the linear algebra, geometric calculations, and physics by hand. That was indeed fun, but it didn't make for good maintainability. These parts of the software should be replaced by more robust and active libraries like NumPy and Shapely. Bear in mind it's important for the libraries chosen to play nicely together.

• [ ] Write unit tests

  If Sobot Rimulator is ever destined to be ready for prime time, it is imperative that it gets the benefit of a comprehensive test suite.

• [ ] Save maps as JSON instead of using pickle

  Pickle is a weird Python-specific object serialization format that is not very portable. JSON, on the other hand, is a universal standard that is found everywhere. It is the obvious choice for defining maps as well as any other data that we may want to persist or transmit in the future.

• [ ] General implementation improvements and code cleanup

  This is a catch-all item for iterating on the existing code and making it better. It should be done on an as-needed basis.

  The bulk of this code was written in 2013, early in my career. Among other things it was practice to get the hang of object-oriented programming. All things considered, I think it came out okay, but with the benefit of many more years of experience it is clear that there are areas for which much better design patterns exist, which would greatly improve the semantics, separation of concerns, general readability, and repository organization.

More Powerful Features

Most of these are big, labor-intensive, and very speculative improvements that would elevate Sobot Rimulator from a limited toy project to a general research and development tool far beyond its current capabilities. With the possible exception of the first two items, I would consider all of these with a big grain of salt, as there are already powerful game development tools and robotics simulators that do much of this. It may not make sense to try to reinvent the wheel. That said, these are a whole lot of fun to think about and would certainly be fun to build.

• [ ] Map navigation improvements

  This thing needs basic map navigation such as panning and zooming.

• [ ] Separate simulation and onboard controller runtimes

  Currently, the "external" simulation of the world and the "internal" onboard robot runtime are tightly coupled, running on a single thread and sharing the same clock. This undermines a fundamental aspiration of this project: to allow the onboard controller code to be easily ported into a real robot.

  To fix this, these two runtimes should be separated as completely as possible, probably by running them on separate threads with independent clocks. To make simulation deterministic and not up to the whims of the system scheduler, the clocks would still need to be synchronized by the parent process, such that the simulation loop executes every dt_s "simulated seconds," and the onboard controller loop executes every dt_c "simulated seconds." The smaller the value of dt_s the higher the fidelity of the simulated world. The smaller the value of dt_c the higher the fidelity of the robot's decisions - though be careful, since values that are too small may not realistically be enough time for the robot to generate control signals. In all cases, the ratio R = dt_c / dt_s must be a whole number greater than or equal to 1.

  One may ask why multithreading is necessary if the entire execution remains synchronized. The answer is I believe it would provide for better isolation of the controller runtime and more closely resemble the environment of running on board real-world hardware.

  I think this would be a really fun and challenging piece of work and a first version of it may not be that out of reach.

• [ ] Support for additional robot models

  The current implementation is specific to simulating the Khepera III research robot. While programmers can implement other robots by hand, there are no well-defined semantics for doing so. A common interface for defining different robot models and loading them into the simulator would be great. Perhaps this could be taken even further, with the development of libraries of sensors, actuators, and structural members that can be mixed and matched to build custom robots.

  Also, this is a good place to note that every robot presents a different array of inputs (sensors) and outputs (actuators) to the on board controller. During initialization, then, there probably needs to be some kind of check to ensure that the controller being loaded can interface with the robot correctly. There are some interesting design questions to think about here.

• [ ] Comprehensive programming model

  The major parts of the software start to become clear now. There is the world map, the robot or robots that will move through it, the onboard control code each is running, and the simulator runtime that ties them all together. In addition there is a GUI "front end" that presents all this to the user and gives them simulator controls. In theory, these elements can be separated into isolated concerns, that can be passed in as arguments to the runtime's entry point:

  def simulate(
    robot,
    controller,
    map="random",
    front_end="kivy",
    options={"clock_ratio": 3},
  ):

  By cleanly separating these concerns, the versatility of the simulator is greatly improved. Different robots can be modeled, users can experiment with and iterate on different control models, and different front-ends can be implemented to allow the software to be run on different platforms.

  As an example, in a previous edit of this post, I speculated about using ipywidgets to enable use of the simulator in Jupyter notebooks. By adding support for an ipywidgets front end, this would become possible from within the notebook:

  import sobot_rimulator as sr
  
  world = sr.load_world("path/to/world.json")
  robot = sr.load_robot("path/to/robot/model.json")
  controller = # ... user implements an experimental controller
  sr.simulate(robot, controller, world, front_end="ipywidgets")
  
  # The output cell displays the interactive simulator demonstrating the
  # behavior of the control scheme.

  At this point, the current simulator.py would simply be a thin wrapper that parses command line arguments and passes them in:

  $ python simulator.py path/to/robot/model.py path/to/controller.py --clock-ratio 1

• [ ] Full-featured GUI

  With this kind of architecture, one could start to dream about a full-featured GUI that turns this software into an industry-ready tool. A front-end could be built on top of this interface that includes drag-and-drop tools for building world maps and for constructing new robots, and an integrated IDE for the controller implementation that allows users to modify, run, save, and load their onboard controller code on the fly, and perhaps even download it onto their robot hardware with a few clicks to try it out in the real world.

[tsadarsh]

I am super excited to see this. I was really hoping to see this project level up soon. Critical Maintanence puts a clear picture of what one should work on first. I personally too felt the need to replace GTK with a more poratble library. ipywidgets sounds promising.

I too am actively researching on alternative widget libraries for my pet-project. I will keep in mind that the widget library is aligned with Juypter notebook. I want to let you know that I am working on replacing GTK library. I will let you know within a week's time if I can take up this part of project.

Overall this roadmap is detailed and well-planned. This may even be the roadmap to a new level of success this project hits :fireworks: .

[nmccrea]

I've edited the original post and made some updates, having had some time to think through some of the items more thoroughly.

Sadly it looks like I will have to leave things there for now, and won't be able to actually tackle these tasks for the foreseeable future. Life is crazy! I hope I can find some time to come back again before long but only time will tell. Getting GTK out of there is a bit of hump to get over. After that, most of the items in Critical Maintenance and Maintainability are pretty low-hanging fruit.

@maddypie I can't tell you how much I appreciate your enthusiasm for this project. I wish I could do more right now. I really hope we can team up on more of this work in the future.