I thought for a while about how to summarize my 2023, as there were lots of ideas bouncing around in my head — some technical, some not so much.
Here’s what stood out as the most consistent theme: I get most of my gratification in how much I’m learning and developing my skills, and how much other like-minded roboticists are able to benefit from the output of my work. I often experience an unhealthy existential tension between how much my day job aligns with these goals versus the immediate needs of the business that pays my salary.
I recently gave a presentation that talked about my combined professional and personal journey so far. One of the slides (pictured below) summarizes things well: it conveys a transition from having a relatively low-stress, non-technical job where I had the time and energy to learn technical things on my personal time, to later getting into “real” robotics where more of the learning happened on the job, but also things get quite hectic as you enter these scrappy environments.
The balance between these competing goals of low vs. high-stress, academic vs. product-driven, and large vs. small companies will set the stage for this post. While I’m selfishly trying to help myself by writing down these ideas into a semi-coherent story, I also believe that this conflict in career choices is not unique to me and may be helpful to many of you readers… or at least interesting.
Open-Source and Community Contributions
In my previous year’s summary post, I had only been a few months into my job at PickNik Robotics. There I cited the company’s open source backbone, the MoveIt framework, as a big reason for my joining, and this has held true.
PickNik is known for having some of the leading ROS experts around the world, so this has certainly propelled my opportunities to connect with the ROS community. So, while my personal projects didn’t get as much as action as in the last couple years, that time and energy went into some pretty cool open-source work this year… including becoming a MoveIt Maintainer!
ROSCon 2023
I got to attend ROSCon for the first time in New Orleans, which was extremely fun and I hope do again in the years to come. The amount of “putting a face to the name” that happened was not only restorative, but quite useful for keeping professional connections strong. Some highlights:
- Met several open-source legends from The Internet™️, including educational legends Ricardo Tellez (The Construct) and Josh Newans (Articulated Robotics), several of my peers from the ROS Deliberation Working Group, and so many other people that you would normally find only on ROS Discourse, GitHub, or various robotics podcasts.
- Got to present on open-source and product work, as well as sit in a panel, for the MoveItCon event that PickNik held the day before ROSCon.
- Met some of the maintainers of the RobotWebTools organization, and in talking to them about our use of their
rosbridgeprotocol androslibjsclient library, they graciously gave me and my colleague Ezra Brooks maintainer access! With this, we’ve been able to work on major updates that include ROS 2 action support for and native TypeScript support forroslibjs. - Landed a lightning talk for my personal project
pyrobosim— you can watch it at the 20 minute mark in this video.
Personal Projects
pyrobosim saw some updates beyond the ROSCon lightning talk. At the time of writing, it has crossed 150 stars, is now being officially versioned, and available on PyPi, meaning that you can pip install pyrobosim to at least get the basic capabilities! To recap,
- 1.0.0 was the initial release.
- 1.1.0 added lots of unit tests and coverage reporting, and the core library is now at around the 80% coverage mark. It also had a few new first-time contributors!
- 1.2.0 includes some basic robot dynamics and low-level velocity command capabilities, which was motivated by a discussion at ROSCon following my lightning talk.
My other popular personal project, turtlebot3_behavior_demos, crossed 200 stars this year. It also saw a first-time external contribution from Kemal Bektaş who upgraded it to BehaviorTree.CPP version 4. This repository was also updated to use the new Groot2 visualizer and better Docker Compose usage, which led to my only other post this year, An Updated Guide to Docker and ROS 2.
Google Summer of Code
Through PickNik, I had the chance to mentor for Google Summer of Code (GSoC) on MoveIt related projects. I was involved as a co-mentor in both of our sponsored projects this year, which can you can read all about on a post I wrote for the PickNik blog.
One important addition to the GSoC content I want to give on this blog is a big shout-out to V Mohammed Ibrahim for his success. I “met” Ibrahim online about a year and a half ago when he offered up his first pyrobosim PR. Since then, he has remained very engaged — he was one of our two GSoC contributors working on MoveIt Servo, earning himself MoveIt core contributor status, and has since started working as a ROS software engineer at KABAM Robotics.
Presentations
Lastly, I gave a few presentations this year:
- Co-presented with my colleague and person-I-want-to-be-when-I-grow-up, Davide Faconti, at the ROS Deliberation Working Group meeting. Big shout-out to Christian Henkel for starting this group in general, as this is exactly my area of focus!
- Gave a presentation on my career path and focus on robot behavior (in Spanish) for the Bolivian university UCB Santa Cruz. Gracias a José Jesús Cabrera por la invitación! The video is not yet available, but I’m happy to share the slides which are in English.
Observations on Open-Core
In parallel to all the open-source stuff above, PickNik has been focusing on its commercial MoveIt Studio software platform. Despite what you may have assumed from the previous section, this is almost exclusively what I work on.
MoveIt Studio is built for high-level behavior of robotic systems, which is right up my alley. Working on this project has been as gratifying as it has been challenging (in a good way). One of my colleagues described MoveIt Studio as ostensibly “the world’s largest ROS 2 integration project”. So you can see that we’re very much in an open-core model situation.
I’m not here to market anything to you. All I will say is this is already one major manifestation of the conflict introduced earlier. Consider this question:
Conflict 1: How much effort should you invest in strengthening the open-source core and making it accessible to all vs. carving out real value in the proprietary offering and moving quickly?
Most people who make a living off open-source will tell you a variation of the same thing: clients are willing to pay for features and functionality that will meet their immediate needs, but ensuring that the foundational software is stable and well-maintained shouldn’t be their responsibility to fund. While this can be discouraging, I don’t think it’s unreasonable; if you’re using someone’s software it’s presumably because you identified some value in it that will save you time in meeting your goals, and not because you want to bankroll general-purpose software tooling… unless you’re an exceptionally wealthy FAANG-like company.
At the same time, most people who use open-source software will tell you some variation of different thing: that sometimes, it can feel overwhelming to have to cleave through a thicket of technical debt and strong opinions from maintainers experiencing the online disinhibition effect even to get a relatively modest piece of work merged back upstream.
It’s tricky. Personally, I try to put up with this because I place a high premium on my work and knowledge making its way to a broader community. On the other hand, as a member of a business trying to get stuff done, it becomes compelling to say “forget it, we’ll roll our own <THING>”… and defer the problem until later on when you find yourself clashing against a previously-made assumption in your solution that promised to solve all your earlier needs. At this point, you maybe empathize with the maintainers of the open-source library.
Does this all sound familiar? If so, welcome to the second conflict:
Conflict 2: To what extent should you write software the “right” way and put the work in to upstream your changes versus doing only what immediately serves the pressing business needs?
As an external observer, your answer will almost always be “of course I’d do the right thing!” This may look obvious, but when you’re placed in a real situation filled with deadlines and, let’s face it, personal preferences, the answer will change. To give a few representative examples:
- If you have a new path planning algorithm to deliver to a customer in a few weeks, are you really going to spend the bulk of that time refactoring an open-source package, passing CI, getting maintainer buy-in, etc. — or are you maybe going to make some concessions to make sure you deliver to the customer on time?
- If you’re a robotics engineer who wants to spend as much time as possible developing the actual path planning algorithms, even if you had time to do the above refactor… do you really want to embark on that wild tangent?
Conflict 3: To what extent should you as an individual go above and beyond in service of writing software the “right” way? And what does this extra effort compromise?
At the end of the day, every technical problem has a human problem behind it. In our path planning scenario, you could actually do the “right” thing and deliver on time if you decide to burn yourself out working extra hours. But that’s not sustainable, so even if you’re someone who holds their work to a high standard, you won’t be able to take this idealistic (and extremely self-destructive) decision in every situation. Something has to give.
On Being a Senior Engineer
I mentioned this to a colleague the other day: A junior engineer only needs to worry about their own work, whereas a senior engineer also needs to worry about the work of others.
Consider the following progression of my GitHub statistics for the last 3 years. While this is heavily skewed by the fact that I started using my public GitHub account for work in October 2022, it still is telling of what it means to work on a project that isn’t just you alone indiscriminately spamming commits to main. Put simply, professional software development needs work tracked and code reviewed.
MoveIt Studio Work
So, what have I been up to on MoveIt Studio all of 2023?
- Development of core software, including lots of refactoring/bug fixes and some feature development. Some of my favorites included vacuum grasp sampling for bin picking applications, converting STL model files to point clouds (also by sampling), and enabling ROS 2 actions for a huge refactor of the entire framework we use for manually controlling robots from a web based UI.
- Managing two SBIRs. The first is on task and motion planning, where I finally got to use ROS 2 Planning System (PlanSys2) in this project and we even put up a few PRs along the way! The other one, which is still ongoing and I am less involved in, is machine learning for affordance detection in manipulation tasks. At least I’ve had some fun playing with Meta AI’s Segment Anything Model (SAM) among other things.
- Helped develop a MoveIt Studio training course and delivered parts of it in several occasions. For those who don’t know, my first “real” full-time job was training content development for MATLAB and Simulink, so this was a nice throwback.
- Worked on a handful of small client projects all the way from hardware integration to developing new features (usually specialized behavior tree nodes) for MoveIt Studio.
Supporting Roles
… but that’s not all! One thing you are told to expect when you join a smaller company is that you have to wear many hats. However, nobody could have prepared me for the sheer number of hats.
Before I became a full-fledged software developer in 2020, I’d spent several years at MathWorks in customer-facing roles, so I have decent experience talking to people… for an engineer. Combining this with working on a product that was just launching publicly, I found myself rapidly thrust into all sorts of sales calls and customer/marketing strategy discussions as we’ve been figuring out where a tool like MoveIt Studio is most effective in the arsenal of a robotics engineer. While this often could become a massive distraction since I… uh… kind of had other work to do, it’s no doubt taught me a lot about the user-facing side of software engineering, dealing with conflicting requirements and priorities, and time management.
I’ve also somehow gone from being a relative newcomer to managing 4 engineers. This is especially funny because my direct reports (and my colleagues in general) are all way more competent than I am, so I mostly just have fun getting to learn from them. One great thing about PickNik, and probably most smaller companies in general, is the unparalleled independence and intrinsic motivation everyone has here. This possibly comes at the expense of having a structured, well-defined role, but I’ll take this option any day.
Different Flavors of Leadership
Leadership takes many forms, but they all are in some way involved with the aforementioned concept of being invested in the work of more people than yourself, and ultimately the business you represent. You thought we were done with the conflicts? Nope.
Conflict 4: How should you balance your own personal career goals with those of the organization you work for?
I will say I’m definitely someone that would prefer to ascend in the ranks as a technical expert, advisor, and mentor rather than the more administrative or business-oriented management alternatives, despite the latter being in much higher demand in the world of reluctant engineers like myself trying to stay technical at all costs.
In my limited experience, it takes discipline and focus to stay in the technical leadership bucket. Your skills have to stand out to be shielded for being sucked into business development (for smaller companies) or middle management (for larger companies). This often means having deep expertise in something that is needed by your organization and that nobody else can do as well. Here are some real examples I’ve encountered.
- You’re a machine learning or motion planning domain expert amidst a bunch of generalist software engineers.
- You’re such a stellar software architect or so proficient at managing client deliverables that the whole company would benefit from your time going exclusively to the thing you’re good at.
- You’re such a great analytical thinker and debugger that you are given big, open-ended research projects that match your aptitude, leaving smaller rapid-fire tasks to others.
My biggest career guiding principle is therefore keeping yourself on the track that best takes you and/or keeps you where you want to be. Whether your goals are to maximize independent learning, shipping real product, or having good work-life balance, you gain a lot in ensuring that your needs and the needs of your employer are comfortably in line. This definitely has a luck aspect — finding the right job at the right time — but it can also sometimes take active effort on your part.
Conflict 5: How can you take action to align your job responsibilities and your long-term career goals?
Earlier in my career, I had a tendency to take my job as-is; in other words, if I felt like I wanted less or more of a certain type of responsibility, then I was just complaining and risked being seen as a bad employee. But you know the saying: the squeaky wheel gets the grease. So, I’ve since learned to shamelessly communicate your goals to your employer, as most reasonable people will do their best to accommodate you if they consider your work valuable. Which comes with the caveat: make sure that you are considered valuable before you do this!
Conclusion
Thanks as usual for sitting through this lengthy end-of-year update, and I hope you’ve enjoyed my candid ramblings on the non-robotics side of robotics engineering.
Related to the “types of leadership” section above, I feel like so far been I’ve been unable to carve a deep pocket of expertise to keep myself in a focused technical role that may some day take me into the hallowed “advisor” status. Or maybe I just don’t see it yet. So, for now I continue to be a generalist frantically jumping from fire to fire wherever I am needed. Many places I’ve worked for love this for the business, and I agree that it’s valuable, but I don’t love this for myself. The book Staff Engineer by Will Larson has been recommended to me, and one of my immediate goals going into 2024 is to read it and learn something useful.
Along these lines, next year I’m trying to be focused on learning something more theoretical in robotics. I believe that optimization-based motion planning and control is the future, so I want to carve time out to play with state-of-the-art software tools like Drake and Pinocchio (and associated packages like OCS2 and Crocoddyl).
I’ve sort of started this effort in 2023, but have nothing concrete to share right now. The goal would be a series of content on motion planning from the ground up using Pinocchio, as I’m excited not only to learn the fundamentals in more depth, but to help leave a mark on what I consider a subdomain of robotics with relatively few good public learning materials. Russ Tedrake’s Underactuated Robotics and Robotic Manipulation courses being one such magnificent exception.
I’m optimistic about what comes next. I find that I’m finally hitting my stride as a “late bloomer” in the robotics software space, and the impostor syndrome is slowly being replaced with a much better alternative; a sense of responsibility to help others avoid their own perceived feelings of inadequacy. Hope you all have a good year!
Merry Christmas! Thanks for posting! Let’s catch up after the holidays.