Hey there! Brandon here.
This was my second time working with Open Robotics, and I’ve greatly enjoyed the culture and the wonderful work done over here. Over the summer I had the privilege of jumping around many different projects and supporting the different efforts (and of course contributing to the open-source ecosystem.)
I was lucky enough to get some of my work released alongside v1.0.0 of RMF, and to also work on a middleware implementation for RMW! So I can say that I finally have a much deeper understanding of the inner workings of ROS2, as well as its super amazing type support and interface generation system.
As most of my experience (both in independent projects, as well as my previous summer with Open Robotics) was mainly dealing with the higher levels of the abstraction stack, this summer was a very big change of pace for me, as I had to pick up many things I took for granted when I was working in those higher abstraction layers.
Unfortunately, I do not have a lot of interesting pictures to show, since I’ve been mostly doing the non-flashy work of handling data and working with middlewares 
Build Tooling for Simulation Builds: pit_crew, traffic_editor, and model_downloader
I built build-automation tools in order to help Open Robotics generate simulation worlds more seamlessly using traffic_editor .
Specifically, I developed the pit_crew library to help allow models to be downloaded from Ignition Fuel to a non-ignition Gazebo model directory as well as sanitise them to ensure that they don’t break any sims. I then folded this into the sim build pipeline, so everything works super seamlessly.
Lots of sanity checks!
Additionally, I helped develop a couple of nifty command-line tools with pit_crew folded in (like a support script to support grabbing assets after traffic_editor and associated packages are installed via .deb files).
I also overhauled how thumbnails are stored and managed, messing around with the ament resource index to allow thumbnails to be found no matter how they are installed (either from source or from a .deb ).
RMF Fleet Adapter Python Bindings
I wrote Python bindings for the C++ robot fleet adapter API from rmf_core , managing memory for it, and writing unit tests and documentation. I was lucky to be able to get this done in time for the RMF v1.0.0 release, so I’m very happy about that!
The bindings are packaged as a hybrid ament package, combining both C++ and Python. (It’s built using ament_python , but the setup.py calls CMake to generate the bindings.)
I also created an example implementation for MiR100 robots using those bindings. (That was a little bit difficult to write blind though, because I didn’t have access to a robot to test it on.)
rmw_zenoh
Writing the middleware implementation for the rmw interface was a veritable boss battle of a project. We wanted to explore an alternative middleware (Zenoh) to improve upon the current scaling constraints with DDS middlewares (particularly with regards to node discovery.)
it was a bit of a challenge because of lack of documentation for rmw , and how spread out the code-base is for any implementations (I had to search through something like 7 different repos, with mostly uncommented code.)
My original tasking was to get a quick prototype of a working rmw implementation that could at least publish strings so that Morgan could compare the performance of Zenoh against some of the other middlewares like FastRTPS or CycloneDDS, but then the feature-set kept growing.
By the end of the summer, I was able to get the following done/implemented:
- Folded in type-support code generation
- Low level memory management
- Data serialisation and deserialisation
- Pubsub
- Service servers and clients
- And message queues for pubsub and services with varying depth
If Zenoh shows promise, it would go a long way towards providing a fully fleshed out implementation for ROS2 that is suitable for extremely large environments with many nodes, which would be a significant contribution to the open-source ecosystem. So fingers crossed!
I was also able to do a show and tell on how rmw and type support works. This was recorded, and the slides can be found here, in case anyone needs a great resource to guide any developments for new rmw implementations.
Sum Up
I’d like to thank Aaron, Grey, Geoffrey, and Morgan for all the support they’ve rendered me during this summer. It’s always refreshing to be working in an environment with so much collaboration, and I don’t think the work from home arrangements hindered us too much.
As always, I will be looking forward to seeing what great exploits Open Robotics has in store for the open-source ecosystem, and I would very much relish the possibility of working with everyone again (either in Singapore or in HQ.)
So this is not a goodbye, but a see you somewhere on the net, and maybe sometime soon 
CH3EERS!