<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>ROS on Matthew Shields</title>
    <link>https://mshields.name/tags/ros/</link>
    <description>Recent content in ROS on Matthew Shields</description>
    <generator>Hugo -- gohugo.io</generator>
    <copyright>© 2022 - 2026 Matthew Shields</copyright>
    <lastBuildDate>Wed, 03 Jun 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://mshields.name/tags/ros/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ROS 2 Camera Calibration</title>
      <link>https://mshields.name/blog/2026-06-03-ros-2-camera-calibration/</link>
      <pubDate>Wed, 03 Jun 2026 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2026-06-03-ros-2-camera-calibration/</guid>
      <description>Preamble – The Why Underlying many perception tasks is the need to express the pose of one coordinate frame relative to another and to compose such poses along kinematic and sensing chains. This allows us to take transform sensor obeservations from the reference frame of a sensing element. This is useful.
A rigid-body pose can be represented by a homogeneous transformation matrix, see here for more on that. \[\begin{equation} \mathbf{T}^{A}_{B} = \begin{bmatrix} \mathbf{R}^{A}_{B} &amp;amp; \mathbf{t}^{A}_{B} \\ \mathbf{0}^{\top} &amp;amp; 1 \end{bmatrix} \in SE(3), \qquad \mathbf{R}^{A}_{B} \in SO(3),\ \ \mathbf{t}^{A}_{B} \in \mathbb{R}^{3}, \label{eq:se3} \end{equation}\] Where \(\mathbf{R}^{A}_{B}\) is a \(3\times3\) rotation matrix belonging to the special orthogonal group \(SO(3)\) and \(\mathbf{t}^{A}_{B}\) is a translation vector.</description>
    </item>
    
    <item>
      <title>Using tmux to Manage a Fleet of Robots</title>
      <link>https://mshields.name/blog/2023-09-04-using-tmux-to-manage-a-fleet-of-robots/</link>
      <pubDate>Sun, 03 Sep 2023 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2023-09-04-using-tmux-to-manage-a-fleet-of-robots/</guid>
      <description>Preamble The title of this post ought to be “Using tmux to Manage a Fleet of Robots Incorrectly”. When I say manage here, I am talking about system configuration, code deployment and systems administration type tasks. Long term you really should be utilising tools like Ansible, Docker and Airbotics to keep your fleets Linux systems running as you intend. However, in reality it is often needed to do some quick maintenance operation to many Linux systems (or robots) at once even in the early days of a robotics startup when you might have a small fleet and maybe not yet settled on a setup using one of the aforementioned “proper” tools.</description>
    </item>
    
    <item>
      <title>PREEMPT RT Install for Ubuntu 20.04</title>
      <link>https://mshields.name/blog/2023-08-30-preempt-rt-install-for-ubuntu-20-04/</link>
      <pubDate>Tue, 29 Aug 2023 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2023-08-30-preempt-rt-install-for-ubuntu-20-04/</guid>
      <description>Preamble I have recently been working with robotic systems that have a greater requirement for deterministic operation. While Ubuntu will likely never be an RTOS the PREEMPT RT patch does allow for soft real-time constraints on specified threads which can be enough of a step up for many research applications.
While there are other guides on how to do this online (some linked below) this post will present as a record for the steps I needed to follow recently for my system.</description>
    </item>
    
    <item>
      <title>Using Chrony to Synchronise System Clocks for Robotic Platforms</title>
      <link>https://mshields.name/blog/2023-08-30-using-chrony-to-synchronise-system-clocks-for-robotic-platforms/</link>
      <pubDate>Tue, 29 Aug 2023 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2023-08-30-using-chrony-to-synchronise-system-clocks-for-robotic-platforms/</guid>
      <description>Preamble If you are utilising multiple Ubuntu systems in your robotic deployment it can be advantageous to have the system clocks synchronised. This is a fairly common occurrence with engineers looking to utilise the distributed nature of ROS and other middleware. If you are interested in this you might also be interested in my previous post on sharing internet connections over a LAN.
Requirements For this you’ll need at least two separate Ubuntu systems connected to each other over a LAN, VPN or similar.</description>
    </item>
    
    <item>
      <title>ROS Python Package Template</title>
      <link>https://mshields.name/blog/2023-01-17-ros-pytho-package-template/</link>
      <pubDate>Tue, 17 Jan 2023 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2023-01-17-ros-pytho-package-template/</guid>
      <description>After spending some time using the C++ ROS package template from Legged Robotics I decided to take a stab at a Pythonic version for prototyping packages in ROS 1.
Check it out, or don’t, I’m easy really.
Hey you! Found this useful or interesting? Consider donating to support.
Any question, comments, corrections or suggestions? Reach out on the social links below through the buttons.</description>
    </item>
    
    <item>
      <title>Sharing Python Code as Modules Between ROS Packages</title>
      <link>https://mshields.name/blog/2022-03-10-sharing-python-code-as-modules-between-ros-packages/</link>
      <pubDate>Wed, 23 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2022-03-10-sharing-python-code-as-modules-between-ros-packages/</guid>
      <description>Preamble We can wrap our code in Python modules within our catkin work space to share with other packages in our ROS environment. Why would we do this? It can be great for code re-usability and wrapping commonly used functions and classes. This can dramatically cut down on repetition of code across your ROS packages.
How To I’m going to start with a fresh catkin work space but feel free to adapt to suit your environment, package naming and file naming conventions.</description>
    </item>
    
    <item>
      <title>Running ROS Nodes on Boot</title>
      <link>https://mshields.name/blog/2022-03-16-running-ros-nodes-on-boot/</link>
      <pubDate>Wed, 16 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2022-03-16-running-ros-nodes-on-boot/</guid>
      <description>Preamble This is a reworking of a blog post that used to be on the Rover Robotics blog, which they have since taken down - sad face.
We often want our robots to be ready to use at the point of power on. We don’t want to be having to call every ROS launch in our stack every time we want to run our robot. Even if you combine all your ROS launch files into one ROS launch to rule them all the following guide will be useful to get you to a more polished robotic product, instead of a development tool.</description>
    </item>
    
    <item>
      <title>Connecting to a ROS Master Over a VPN</title>
      <link>https://mshields.name/blog/2022-03-12-connecting-ros-master-over-vpn/</link>
      <pubDate>Sat, 12 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2022-03-12-connecting-ros-master-over-vpn/</guid>
      <description>Preamble This is a nice build on from my previous post on creating a VPN server. If you are using ROS and a VPN server it is possible to remotely connect to the ROS master on one of your robots from either another robot or other device. Basically the only requirement is that both systems are clients on the VPN and can run ROS. It also helps if you have provisioned each system with a static IP address, again details are in my previous post on creating a VPN server.</description>
    </item>
    
    <item>
      <title>Operational Considerations for a Robotics as a Service</title>
      <link>https://mshields.name/blog/2022-02-15-reports-from-the-frontline-of-raas/</link>
      <pubDate>Tue, 15 Feb 2022 00:00:00 +0000</pubDate>
      
      <guid>https://mshields.name/blog/2022-02-15-reports-from-the-frontline-of-raas/</guid>
      <description>Preamble Surely whole point of a robotics as a service (RaaS) is to deploy robots and get paid. But there are a lot of considerations that are easy to overlook when making sure you are ready.
The idea for most people who get into this field often looks something like this:
Design a robot Build some of those robots Deploy them … Profit? But inside those ellipses be dragons. Let’s try and figure out how to conquer them.</description>
    </item>
    
  </channel>
</rss>
