Welcome to my 2025 recap post, continuing the tradition since 2020.
Some things have not changed; I’m still too busy, both with my job at the Robotics and AI (RAI) Institute and with a few efforts on my personal time. In other ways, things have changed; much of my activity has shifted over to the supervisory side. I’m now managing and advising people in several aspects of my life. I’ve found myself navigating the experience of being unable to do so much of my own individual technical work, while at the same time having access to a growing set of people all over the world that can do the work better and with more time and energy to focus.
This post contains 3 major sections: the “brag sheet” of things I did this year, the “existential crisis” of being a supervisor and emerging theme of developer experience, and the “looking ahead to 2026” conclusion.
Summary of 2025
Presentations
This was another surprisingly full year of invited talks!
(February 2025) Visited the University of Washington (UW) in Seattle to present at their 2025 Winter Colloquium series, with a talk titled Towards Task Planning with Learned Manipulation Skills. This was the most intimidating talk I’ve prepared so far because I was sharing the stage with some heavy-hitting academics, despite not being an academic myself. Thanks to advice from my colleagues, I was able to lean into my software-in-a-research-setting background and put together something unique to my strengths.
This packed visit to UW was hosted by Professor Siddhartha Srinivasa, and it was amazing getting to meet him and see his lab. I also had one-on-one meetings with UW professors Maya Cakmak, Dieter Fox, and Abhishek Gupta and met many other graduate students and postdocs. Big thanks to the main facilitator: my former colleague Ashton Larkin who was a student there at the time (also, thanks for picking me up from the airport).
(March 2025) Recorded a repeat episode on Chandandeep Singh’s Learn Robotics and AI Podcast. We first met and recorded a 3-part series in 2022, when I had just started at Boston Dynamics. Chandandeep and I have since kept in touch and decided to do a more informal “catch-up” chat on how my career and the field of robotics have changed over the last few years.
(July 2025) Gave my first ever talk to middle/high school students! GummyBears Robotics, a FIRST LEGO League team from Westford, MA, invited me to one of their summer meetings. This was super fun, because the kids and parents had a lot of great questions and reactions to the robot videos. While this talk wasn’t recorded, you can find the slides at this link.
(October 2025) Attended ROSCon 2025 in Singapore! Again, there are more details in my full ROSCon 2025 post, but to summarize:
- Because one intimidating presentation wasn’t enough, my colleague Tiffany Cappellari and I presented the keynote talk at ROSCon this year, titled Advancing Robot Learning with ROS 2. Huge thanks to Tiffany for carrying the team and to our colleagues (especially Jenny Barry) for their feedback which really improved the talk from its original form.
- Presented a workshop on Reinforcement Learning for Deliberation in ROS 2 with my ROS Deliberation Community Group co-moderator, Christian Henkel. Thanks as always to Christian for always finding more exciting open-source ideas to keep me away from having a life… but seriously, it turned out great.
- Was interviewed by Josh Newans (better known as Articulated Robotics) on his ROSConversations ’25 video.
(December 2025) To bring it all full circle… Niveditha Kalavakonda, who reached out to me after my visit to UW, is a host of the Talking Robotics presentation series and extended me an invite. I snagged their final slot of 2025 to try a new topic I’d been thinking about this year but never got around to fleshing out. This talk, titled Robots are complex, but your systems don’t have to be, very much relates to the theme of this post.
Open source involvements
Open-source software (OSS) sucks you in and never lets you go. Here is proof via my summary of contributions this year.
ROS involvement: Through our ROSCon 2025 efforts, in that both our talk and workshop was AI focused, we at the RAI Institute landed invites to the Physical AI special interest group run by the Open Source Robotics Alliance (OSRA). This has been a good opportunity to work more closely with some OSRA members and fellow robot learning enthusiasts from other organizations. I personally have been playing with the mujoco_ros2_control repository to help put together some robot learning demos, which you should absolutely check out if you are doing simulation work with ROS!
PyRoboSim: My little hobby simulator project from 2022 had another batch of improvements this year. This year’s release highlights are:
- 4.0.0: Type annotations enforced with
mypy, which was a direct effect of seeing how great Python type hinting was at work, and wanting to carry that into my personal projects. Also added sensor plugins with a 2D lidar implementation, improved path planner plugin registry to match the sensors, and completed the world resetting feature that was partially introduced in previous releases. - 4.1.0: UI toggles for visibility control, contributed by Ayush Patel. Ayush also reported a couple of good issues using PyRoboSim for his own work on a larger-scale, realistic map of a building. One even resulted in a small upstream fix to the Shapely library.
- 4.2.0: Partially observable hallways detectable with lidar. This was a challenging feature contributed by Woon Tian Tien, who did a fantastic job iterating with me and getting the original proof of concept up to quality.
- 4.3.0: Significant improvements driven by our Reinforcement Learning workshop at ROSCon. Turns out that you can find a lot of performance/robustness issues when you run the simulator headless and keep blasting it with rapid-fire commands for hours to control robots, reset the environment, etc. You should absolutely upgrade to this version because in my opinion it’s another big step forward in the software’s maturity.
RoboPlan: I also discuss this in more detail in my ROSCon post, since I presented it as a lightning talk. Long story short, I dropped a few related motion planning projects to try something new that focused all my efforts. With some former colleagues, Erik Holum and Jafar Uruç, we put together a proof-of-concept motion planning library written in C++ using the Pinocchio library, with “proper” Python bindings and support for visualization, hacking, and debugging. As part of this adventure, I got to try out the amazing nanobind and Viser tools, and even added official support for Viser in Pinocchio.
PyTrees: In last year’s update, I mentioned getting the “keys” to the PyTrees repositories from the original author, Daniel Stonier. Since then, I found some time to follow through and cut releases 2.3 and 2.4 on PyPi and the newest ROS distros. This mostly consisted of getting everything running on the latest versions of Python and ROS, as well as fielding a few community contributions and reported issues.
I’ll also advertise this Git issue if anyone wants to help switch PyTrees to use uv as a package/project manager instead of the dated tools that are currently in place.
Mentorship and Advising
This has been a rewarding yet challenging year in terms of exercising my mentorship muscle. Not only did I become a manager at work (more on this later), but I also landed on a couple other interesting opportunities.
- Women Coding Community: I found WCC in an attempt to reach a more diverse audience of robotics engineers. While it seemed more geared towards general software engineering, I anyways decided to volunteer as an inaugural robotics-focused mentor. It was a pleasant surprise to see such a large volume of applicants; in fact, I ended up convincing some colleagues (Tiffany Cappellari and Griswald Brooks) to help out. Overall, the 3 of us were able to connect with at least 8 roboticists at various career stages through this program in 2025. Whether you are looking to be a mentor or mentee, consider participating in WCC next year!
- Advising a startup: At the end of last year, I met Shankara Narayanan, who was wrapping up his Master’s degree at Northeastern University. Over coffee, Shankara told me he was about to move out to the San Francisco Bay Area to co-found a robotics startup, and asked if he could ping me every now and then to ask me questions about software. Why not, right? From that point on, the startup has been moving fast; in September, I got to visit them in Palo Alto and check out the robot they had built from scratch since their inception in January. We’ve since established a more official advisory partnership, where I regularly meet with some of their engineers (shoutout to Suresh and Jaiv) to offer advice. The company has recently come out of stealth, and you can check them out at https://tangiblerobots.ai/.
* takes a deep breath *
Why Developer Experience?
As I was brainstorming ideas for this post, I noticed parallels in my work and educator/open-source contributor lives that cemented the theme of developer experience. Positive developer experience is when the software and tooling you are working lets you easily implement and validate new ideas. Conversely, negative developer experience is when the software and tooling seems to be working against you, affecting your productivity and overall morale.
Developer Experience in the Research World
A few things were shaken up at my work (RAI Institute) earlier this year. Our original project team split into two, while also being placed within a larger Manipulation organization with a few other groups. I was put in charge of one of these teams; specifically, a small group focusing on composition of learned manipulation skills. You can get the general gist from my UW seminar presentation, but the talk happened right before the split, so our technical approaches have changed directions since then.
I’ve been a manager twice before, but in both cases I was a kind of second-in-command who operated more as a technical advisor/unblocker while the main leader focused on the high-level team goals. This has been my first time on the hook for fully setting the work direction for my team, and it has been challenging for a few reasons:
- I haven’t done it before, so I’m going to be bad at it initially. Yes, it will take building up some experience, but I am also reminded of the Peter principle.
- I still feel wildly uncomfortable with the research side (which is our main deliverable), and tend to fall back to my software developer/product tendencies in a way that can favor constant firefighting over longer-term research ideas. Fortunately, my team feels extremely comfortable to share what’s on their mind when I stray too far. I think this has led us to converge on directions that make a lot more sense, even if sometimes it takes some back-and-forth discussion. Having a project manager has also been incredibly helpful here.
- Now, immediately falling back to my software developer/product tendencies… we accumulated an astonishing amount of technical debt in our previous team’s “everyone-for-themselves” way of operating. Over the last few months, we took some extreme detours, including efforts to consolidate software, move to a new build system, standardize all our robot stations in the lab, thereby building a brand new pile of technical debt. I’ve tried to remain as hands-on as I can to firsthand experience the pain that our teammates are feeling and… let’s say it’s been a good idea to keep a pulse on that (you can ask any of my software engineering colleagues how much of a nuisance I’ve been to them). Anyways, this has taken time and focus away from the whole “research lead” thing I’m supposed to do.
If I had opted for the hands-off management approach, it would have probably been easier to tell my team “tough luck, this is now our shared infrastructure and I’m sure you can make it work”. Maybe I even tried to say this at the beginning. However, spending time to understand what issues people are facing daily helps you realize that it’s hard to be a productive engineer, researcher, scientist, etc. if you’re working on a shaky foundation. In the worst case, people will flounder in the chaos and get nothing done; in a not-as-bad-but-still-pretty-bad case, people may be capable enough to figure out how to operate in such settings, but they won’t be happy to do it. So they they eventually may give up and do their own thing, or decide to leave for greener pastures. All of these reactions are completely valid, and something I didn’t expect to be such a large part of my manager role.
Developer Experience in Open-Source Software
You may be wondering: are these same issues present in open-source software when people aren’t being paid to figure out how to play nice together? The answer is “yes, and here’s a whole other section explaining my experience”.
In the same way that a hands-off manager could force people to “just figure it out” from a place of insufficient empathy, in open source software there is the archetype of experienced, but jaded and incredibly gatekeepy developers. They respond to all the poor, well-intentioned newcomers struggling that this is a skill issue, they should git gud at coding, and so on. I strongly disagree with this way of operating; I believe that if people can’t figure out how to use your code, that is most often a failure on your part, not theirs.
For readers who find themselves on the receiving end of this, you should take comfort in knowing that you are not the problem. I’m not saying that learning a new skill should be easy and you never have to try, but you should at least feel like you can make steady progress in your learning without getting stuck and having nowhere to turn for help.
And so, we come to my motion planning adventure.
At an earlier, but not so distant, point in my career, I believed that all these popular open-source tools for motion planning were popular for a reason, and that it was my duty to be a good enough developer to muscle through and figure them out. This is partially true; a lot of effort and time goes into these tools, much of the work has already been done for us, and to some extent it would be foolish to not take advantage of that. Even so, as I was trying to dig into the software and learn more deeply how it worked, I realized that a lot of this complexity came from an accumulation of technical decisions that in isolation seemed harmless, but over time created some pretty nasty codebases that were extremely off-putting to newcomers like me.
In the diagram below, we see two clusters along a capable-simple curve. These open-source monoliths like Drake, MoveIt, and Tesseract are as powerful as their code is complex. On the other side, you have these “teach pendant” like software tools that allow you to easily (sometimes even without any code) put together simple motions such as point-to-point, linear, and circular motions; in the industrial world, shortened to PTP, LIN, and CIRC.
The purple line describes a Pareto front.
At PickNik, we were building a product that tried to make MoveIt easier to use via low-code, graphical programming of behavior trees. However, many of us were not thrilled about the state of MoveIt and our inability as a business to find the sufficient resources to breathe life into the open-source core. We often talked about a “scorched earth” approach where we would rewrite MoveIt to be clean and free of the baggage it had gathered over the last 15 years. However, the reality is that this is wildly impractical. Switching software stacks requires the new thing to be significantly better, and it would take a tremendous amount of time to even establish parity with all that MoveIt has to offer — again, very distracting for a business.
My first adventure after leaving PickNik was writing PyRoboPlan, which I talk about at length in my 2024 posts. This was driven by self-learning within a simple codebase, wherein I decided to implement basic motion planning algorithms for robot manipulators purely in Python, using the Pinocchio library. Shortly after, my former colleague Ashton Larkin did the same with MuJoCo as a backend, naming it mjpl as a nod to the Open Motion Planning Library (OMPL). These pedagogically-focused tools are certainly more capable than industrial software, but to say they come close to the established open-source frameworks would be an outright lie.
When I started at the RAI Institute, we similarly had a need for motion planning solutions to perform baseline tasks with our robot arms. Given the freedom our research environment offered, we chose to implement our own motion planning stack inspired by the catalog of tools above. We landed on a C++ based tool for performance, and because we were using ROS we borrowed some design choices from MoveIt: specifically, tight coupling with ROS middleware and the use of abstract base classes for components managed at runtime by pluginlib. With these 2 decisions followed a lot of YAML engineering, as is often the case in the ROS ecosystem. With a core team of about 4 people, myself included, we stood up some basic capabilities and unleashed them on our research colleagues.
The overwhelming reaction? “This is really complicated, no thank you.”
The critical error? We didn’t try to solve the actual motion planning problems that people needed solved! We made a framework just as complicated as MoveIt, but with almost none of the functionality, expecting the blanks to be filled in later by others. New feature development was intimidating. When something went wrong, our colleagues were unable to easily debug problems. And so, our internal stack got stuck in the dreaded “complex, but not capable” corner. After the release, I tried for a few more months to keep maintaining the code and simplifying, adding more tests, incorporating logging and visualization tools for hard-to-debug critical spots… but it was too late. People already had a bad first impression and moved on to solving their own problems with simple Python code. My motivation to keep improving things fizzled out. I consider this project a failure and have also moved on.
All this led me to try RoboPlan as a side project, mostly to prove to myself I could do better and make something of value to the community if I was lucky and/or successful. Could I try the same C++ based library but decouple it from ROS, making it as easy to use as PyRoboPlan via Python bindings? Designing a system that works in the ROS ecosystem, but also is available standalone via packaging environments like PyPi and conda-forge, is actually pretty challenging… and this is my next step in figuring out how to build something that balances capability with positive developer experience. Luckily, this tool is open source which means anyone can help. Please help.
Designing for Positive Developer Experience
No software will ever be the perfect utopia of productivity. In practice, though, there is a minimum bar to hit; people working on the code should feel that, while things may not be ideal, they can get stuff done and it would be impractical to switch solutions. If that basic requirement is not met, then it’s a problem that has to be solved immediately.
All these thoughts about developer experience culminated in my Talking Robotics presentation. The talk begins with the idea of approachable software, which is described by the properties in the image below.
The presentation concludes with 4 guiding principles for building approachable software. I did change their order from the presentation to make things flow better in text form.
1. Don’t reinvent the wheel (unless the previous wheel was square…)
It’s normal to see code you don’t understand right away and say “I can write something better”. However, we often underestimate the cost of building an entirely new tool.
My first piece of advice is to seriously consider whether you should embark on such a time-consuming project. I would recommend starting by taking the time to learn about alternative tools you are considering. Hack out a proof of concept to convince yourself whether these tools will work; only if you find a good reason they won’t, should you go for something new. If there are some non-ideal aspects of the software, but you can see a path towards fixing them, even better! Improving software for other people is often a good and rewarding decision, and useful material for your resume.
When should you consider reinventing the wheel, then?
- Novel idea: This is the most obvious one. If you’re working on a sufficiently new idea that has no real viable alternatives, then congratulations — you’ve got yourself a nice opportunity to make an impact.
- Incompatible use case: Sometimes, what you want is out of scope for existing tools, by design. For example, if I made a pure-Python library for education and a user complained that it’s slow and they want to improve it with a Rust backend, I would tell them this would compromise the educational aspect to the point that they should just do their own thing.
- Baggage over time: Some software works just fine, but may have “aged out” due to technical debt from tweaks over many years, or due to the release of better, more modern tools that did not exist at the time of creation. In some cases, it is preferable to take inspiration from old code and do a more modern rewrite vs. fixing what is there and sifting through all the accumulated baggage just to make incremental changes.
- Death by abstraction: Many developers believe that creating convoluted code filled with inheritance, design patterns, etc. is a sign of their expertise. This stuff can be useful in moderation, but if you’re working with code that is near impossible to understand, and you can’t envision yourself figuring out how to make improvements to it while in a positive headspace, that can be a good forcing function to out-compete the status quo with simpler alternatives (though again, see if you can fix it first).
2. If you can’t avoid complexity, be ready to explain why
Coming out of the “death by abstraction” point, let’s talk about complexity that can be avoided. In my experience, I’ve seen two main ways to get around this.
- It’s okay to copy-paste a few lines of code if it means reducing complexity. Better yet, if you can make duplicated code into a reusable utility function rather than going for more complex patterns you can avoid both problems! When I see overly complicated code, it discourages me from making contributions. Sometimes, I’ve been able to push back on complexity through design or code reviews or teaching by example (i.e., contributing fixes for authors to review). However, persuading people to change their ways can be mentally exhausting, especially if people get defensive about criticism. In some cases, you may not have a choice and need to expend some of this energy, but in other cases it may be worth disengaging and finding alternatives that feel more productive.
- Avoid making new layers of abstraction that don’t actually enable anything new. In my time as a developer, I’ve seen many such tools being brought up. The usual trend is that someone doesn’t take the time to understand how a piece of software works, so they write an “easy to use” wrapper that hides away the difficult parts. What ends up happening is that you make simple things simple, and hard things nearly impossible. Even worse, you suddenly have a whole new layer of code which makes debugging and maintenance more challenging. Instead of adding more layers, ask yourself whether you can get away with direct contributions to the existing software, like documentation, examples, fixes, or simply spending a little more time mastering your tools.
Now, there are situations where that extra layer of abstraction, judicious application of a design pattern, unreadable but performant code, etc. is necessary. If you find yourself in such a situation, then your job is to convince people this is true. How do you do this?
- Provide clear motivation. Normally, this involves your software’s documentation having a “Concepts” or “Design Philosophy” section that explains how it was designed and what key aspects users may need to understand before jumping into the code. For example, you could say things like “this tool was created to be extensible, so we have built a registry for users to add their own behaviors at runtime”. Here is also where the video format works surprisingly well, whether you decide to record your own introduction video or link to any presentations you may have given in the past.
- Create documentation and examples. Once you’ve explained the high-level concepts, you need to give people the necessary help to understand your code through documentation and examples.
- Documentation — both dedicated docs and code comments — can help explain those tricky spots where you may have needed to be a little clever to make certain things better, or even possible. As people ask you questions about your code, consider whether there is an opportunity to add documentation, thereby reducing confusion for the next people that come along with similar questions.
- Examples, on the other hand, will help users practice working with your code and decide whether it meets their needs. If your concepts page describes a registry for users to add their own behaviors, then there better be an example of how to use said registry to add your own behavior! if A good set of examples could even help users understand why you made certain decisions through firsthand experience.
Self-documenting code? Get outta here with that nonsense. Where are the examples?
3. Prioritize the ability to troubleshoot
Even if you’ve convinced people that your code is worth using, you’re not in the clear. When people inevitably run into problems down the road, their ability to troubleshoot could make or break their developer experience and cause them to reverse their decisions. Here are a few recommendations to address these risks.
- Make core functionality usable in isolation. I’ve seen this a lot in the ROS ecosystem, because it is easy in the short term to intertwine the core functionality of your code with the middleware (ROS pub/sub and the like). Before you know it, you’ve built up a system that you can only really get working by starting up a multi-process launch file, each with multi-threaded components. When the time comes to debug a small pocket of code, you may not be easily able to isolate it. The result? Pain. Some solutions?
- Write unit tests: Unit tests have obvious benefits in… well, testing your code and preventing future breakages. However, one important side benefit is that writing tests forces you to architect code to be better isolated. Chances are that if your core functionality relies on too much stuff like database queries, web API calls, ROS messaging, etc. it’s going to be really hard to write a unit test for it that doesn’t also spin up the whole system behind it. Unit tests have yet another benefit in that they can sometimes behave as “examples” to help users understand the intended use of your code. So yeah, write tests; if you can’t do this easily, you may be looking at some refactoring in your future.
- Separate the core and integration layers: Consider an example where you’re writing a path planning algorithm as a ROS node. Try to write the path planner completely without ROS; that is, plain functions or classes that you can easily test. Then, you can create a “wrapper” ROS node that brings up your path planner and interacts with it via the same high-level functions you used in your tests. Taken further, this allows you to create modular code that supports multiple middleware implementations; also, in the event that you ever need to switch out your communication layer you don’t have to do any surgery to extract out your code. (In fact, ROS 2 maintainers did this with their middleware layer which in newer versions lets users swap from DDS to the more modern Zenoh.)
- Visualization and logging is key. I’ve taken part in both building and debugging software that gives you no easy indication that it’s working correctly. As a result, I’ve had success every time I’ve decided to add the ability to visualize and log data in problematic code. This year alone, I worked on the following:
- Used the DataTamer/PlotJuggler combo to log data from a problematic motion execution node written in C++. I highly recommend these tools for C++ codebases!
- Picked up Viser to create robot path planning visualizations and interactive markers for the examples in RoboPlan. As described in the previous guideline, it’s very important for examples to offer this kind of interactivity for users.
- Tried Rerun for the first time to visualize imitation learning data as part of a big debugging effort at work. Fun fact: I found 2 bugs in our code while working on this visualizer, and I’m sure more will be found by my colleagues now that it exists.
4. Build a community first, optimize later
The first three guidelines are important with respect to building the software. However, we can’t ignore the human aspect behind software. Ultimately, If people can’t figure out a piece of code and have nowhere to turn, they will find an alternative, which can fragment the user community. How can we prevent these issues?
- Avoid premature over-engineering. We’ve already discussed complex code at length, but I want to speak to the human side of this problem. You may have an abundance of clever ideas for improving your code that you are excited to implement, or you may be programming “defensively” in anticipation of use cases that never actually happen. There is a principle in the software world, “You aren’t gonna need it” (YAGNI), which I subscribe to after experiencing what happens when you don’t apply it. Implementing only what is needed, when it is needed, improves the chances of other contributors jumping in to help with features and fixes that would otherwise be too intimidating to develop in a more complex, prematurely (over)designed, code base.
- Be available to provide support. No matter how good your code is, people will still find issues with it as long as the sky is blue. My final suggestion is to make yourself available to respond to these issues, be it through Git issues, discussion forums, or chat clients (Slack or Discord, for example, are popular these days in open-source software). Being a responsive and kind maintainer, instead of a “competent jerk” goes a long way, because it helps your software build a good reputation. For example:
- The maintainer of Viser (Brent Yi) is extremely responsive. He has helped me and many others on social media with a handful of issues that actually ended up improving his software dramatically. See this Git issue for a great example.
- Companies that maintain open-source tools like Rerun and Pixi have vibrant Discord servers where lots of questions get answered. I personally had a great experience on the Rerun servers when facing issues with displaying URDF models.
You shouldn’t think of people’s issues with your software as a distraction. More often than not, you can convert user confusion into concrete improvements for your software and/or its documentation. Sometimes what you thought was important is not important at all to the majority of users, and conversely you might have missed out on something critical in your original design that user feedback could help expose. In 2024, when I collaborated with 5 people on using PyRoboSim for a ROSCon workshop, I received an overwhelming amount of feedback about functionality I hadn’t even thought of. It kind of sucked at the moment to have fallen so short of their expectations, but acting on these comments unmistakably made PyRoboSim better. I recommend you also go along for the ride once your code starts getting used and scrutinized by others.
The takeaway?
Take some time to figure out the human problems first, and you’ll be able to solve the technical problems faster!
(By the way, you can find my slides here.)
Plans for 2026
Admittedly, I felt quite self-conscious writing this much about developer experience. Not that I think I’m wrong about too much of it (you can’t be wrong with subjective things like these anyway), but I worry about being someone that gets stuck on philosophy and architecture and ends up getting nothing substantial done. So even you, readers, should take this advice with similar skepticism. Whatever you do, please make sure you’re solving real problems for yourself and for others. That is the most important thing of all.
My 2026 plans are simple: follow through with all the open threads. Specifically,
- Getting my head out of this “developer experience” fixation and ensuring I keep myself and my collaborators contributing meaningfully to the field of robotics. I’m not saying I’m throwing away all this advice for myself after typing it out, but rather aiming to push it to the background in service of the real goals.
- In case you’ve been living under a rock, Machine Learning (ML) is kind of popular in robotics. Through my work in the ROS Physical AI group, or other upcoming collaborations, I’d like to work on open-source educational materials that take advantage of tools such as MuJoCo and LeRobot to apply ML to robot manipulation.
- Continue working on RoboPlan. There is so much more to do, both on infrastructure and new features. We already have a few contributors gearing up, but we are always looking for more. A goal for 2026 is to put this project up on Google Summer of Code so some contributors can get paid for their efforts.
- These is a convergence of the motion planning and ML goals. I’m interested in motion planning applied to robot learning, because it gets away from the old-school notion of pre-planned trajectories that must avoid collisions in static environments. State-of-the-art manipulation embraces contact instead of avoiding it, and it would be great to make RoboPlan a tool that serves these evolving needs. With less baggage compared to older software, the opportunity is basically screaming at us!
- Mentoring for Women Coding Community was extremely rewarding and I plan on participating again. If you’d like to join WCC as a mentor, or you know of any other diversity-focused robotics programs that need a hand, let me know.
Thanks for reading another post that came out way longer than anticipated. If anything here resonates with you, or you’d like to help with some of the open-source or mentorship efforts described in this post, I’d be happy to hear from you!
Thank you for sharing your learnings and experiences 🙂