tinyros 0.1.0

TinyROS: A lightweigth ROS implementation for GPU-first robots.

TinyROS

A minimal Robotic Operating System for GPU-first robots.

Features:

• .... I will finish this README soon

Installation

pip install tinyros

Example

Soon. You can check out the tests for now, in particular test_architect.py

Why TinyROS?

You know it :D

Questions

Please open a separate GitHub issue for each question or requested feature.

Citation

If you use TinyROS in your research (you should, drop ROS/ROS2!!!), please hand out a citation:

@software{terpin2025tinyros,
  author       = {Terpin, Antonio},
  title        = {{TinyROS}: A Lightweight Robot Operating System for GPU-first robots},
  year         = {2025},
  version      = {1.0.0},
  url          = {https://github.com/atrepin/tinyros},
}

Contributing

The Coding style validation action will fail if the pre-commit checks do not pass. To make sure that these are checked automatically on push, run:

pre-commit install --hook-type pre-push --install-hooks

To run the pre-commit checks on specific files:

pre-commit run --files <files>

To run on all files:

pre-commit run --all-files

If for some reason you really want to ignore them during commit/push, add --no-verify.

To ease writing commit messages that conform to the standard, you can configure the template with:

git config commit.template .gitmessage

To fill in the template, run

git commit

When you have edited the commit, press Esc and then type :wq to save. In Visual Studio Code, you should setup the editor with

git config core.editor "code --wait"

You may need to setup the code command. The Commit style validation action will fail if you do not adhere to the recommended style.

Tip: When something fails, fix the issue and use:

git commit --amend
git push --force

Development workflow

We follow a Git feature branch workflow with test-driven-development. In particular:

• The basic workflow is as follows:

  1. Open an issue for the feature to implement, and describe in detail the goal of the feature. Describe the tests that should pass for the feature to be considered implemented.
  2. Open a branch from dev for the feature:

  git checkout dev
  git checkout -b feature-<issue-number>
  

  3. Add the tests; see Testing.
  4. Implement the feature and make sure the tests pass.
  5. Open a PR to the dev branch. Note that the PR requires to squash the commit. See Preparing for a PR.
  6. Close the branch.

• main and dev branches are protected from push, and require a PR.

• We run github actions to check the test status on push on any branch. The rationale is that we want to know the state of each feature without polling the developer.

• We open a PR to main only for milestones.

Testing a feature

We will use pytest to thoroughly test all our code. To run all tests:

pytest -v

Before pushing a feature, implement also the related test. The goal is to make sure that if something does not behave as expected (possibly as a result of another change) the tests capture it.

Preparing for a PR

Before opening a PR to dev, you need to squash your commits into a single one. First, review your commit history to identify how many commits need to be squashed:

git log --oneline

For example, you may get

abc123 Feature added A
def456 Fix for bug in feature A
ghi789 Update documentation for feature A

Suppose you want to squash the three above into a single commit, Implement feature <issue-number>. You can rebase interactively to squash the commits:

git rebase -i HEAD~<number-of-commits>

For example, if you want to squash the last 3 commits:

git rebase -i HEAD~3

An editor will open, showing a list of commits:

pick abc123 Feature added A
pick def456 Fix for bug in feature A
pick ghi789 Update documentation for feature A

• Keep the first commit as pick.
• Change pick to squash (or s) for the subsequent commits:

pick abc123 Feature added A
squash def456 Fix for bug in feature A
squash ghi789 Update documentation for feature A

Save and close the editor. Git will prompt you to edit the combined commit message. You’ll see:

# This is a combination of 3 commits.
# The first commit's message is:
Feature added A

# The following commit messages will also be included:
Fix for bug in feature A
Update documentation for feature A

Edit it into a single meaningful message, like:

Add feature A with bug fixes and documentation updates

Save and close the editor; Git will squash the commits. If there are conflicts during the rebase, resolve them and continue:

git rebase --continue

Verify the commit history:

git log --oneline

You should see one clean commit instead of multiple. If you’ve already pushed the branch to a remote repository, you need to force-push after squashing:

git push --force

Now that the feature branch has a clean history, create the PR from your feature branch to the main branch. The reviewers will see a single, concise commit summarizing your changes. See the guidelines for commit messages.