Ted Kern
6 posts
The myriad of different fields that make up robotics makes QA practices difficult to settle on. Field testing is the go-to, since a functioning robot is often proof enough that a system is working. But online tests are slow. The physical environment must be set up. The entire system has to be in a workable
Linux containers allow for easy isolation of developer environments. If you’re often working with a bunch of different ROS versions, it’s a lot easier to do your work entirely in containers. Getting Started You’ll first need to install LXD using snap. Note Throughout this guide I will be using the hostname to distinguish which machine
The ROS 2 Tooling Working Group (chaired by AWS RoboMaker) has been hard at work producing a neat set of GitHub Actions for building and testing ROS packages on a variety of different systems. They work great on Ubuntu targets and preliminary support is already present for MacOS and Windows, making them a great option
The end of 2019 brings about the latest ROS 2 release – Eloquent Elusor. Despite an ever growing set of features and some changes throughout the ecosystem, packaging with snaps is as easy as always. Let’s go through a quick example! Prerequisites You’ll need two tools: “snapcraft,” the program that builds snaps, and “multipass,” the
A well configured linter can catch common errors before code is even run or compiled. ROS 2 makes it easy to add linters of your choice and make them part of your package’s testing pipeline. We’ll step through the process, from start to finish, of adding a linter to ament so it can be used
One of the most common complaints from developers moving into large Python codebases is the difficulty in figuring out type information, and the ease by which type mismatch errors can appear at runtime. Python 3.5 added support for a type annotation system, described in PEP 484. Python 3.6+ expands this with individual variable annotation