What Do Robotics Engineers Actually Do? A Day in the Life at Fictionlab

TL;DR: A typical day for a robotics engineer at Fictionlab mixes ROS 2 development, CAD revisions, soldering, outdoor field tests, and a fair amount of debugging logs over coffee. We design, build, and support open-source and ROS-based mobile robots like the Leo Rover and Raph Rover, which means we switch contexts often: firmware in the morning, a muddy parking lot at noon, a customer integration call in the afternoon. This article walks through what that looks like in practice, what tools we reach for, and what we have learned about building UGVs that survive contact with real research environments.

Why “a day in the life of a robotics engineer” is hard to summarize

Ask ten people what a robotics engineer does and you will get ten answers, most of them partially correct. The role sits at the intersection of mechanical design, electronics, embedded firmware, middleware (in our case, mostly ROS 2), perception, and customer-facing engineering. At Fictionlab, where we build mobile robots and ship them to universities, research labs, and integrators around the world, the role gets even broader because we also maintain the open-source stack used by Leo Rover deployments in the field.

So instead of giving an abstract job description, it is more useful to show what a day actually looks like: the standups, the test drives, the failed pull requests, and the small wins. That is what this post is about.

What a morning looks like: ROS 2, CAD, and the first coffee

Mornings tend to be the quietest part of the day, which is when most of the deep work happens. A robotics engineer at Fictionlab usually starts by skimming overnight CI results, GitHub issues from the community, and any new tickets from B2B customers running Leo Rover or Raph Rover platforms. The open-source nature of our stack means that bug reports can come from a lab in Tokyo, a university in Texas, or a field robotics group in Norway, all before 9:00 AM Central European Time.

Once the inbox is triaged, the work splits roughly into three streams, depending on the engineer’s focus that sprint:

• Software: writing or reviewing ROS 2 nodes, tuning the navigation stack (Nav2), updating the URDF, or improving the web UI used with the rover.
• Hardware: iterating on a chassis part in CAD, validating a new motor driver, or laying out a PCB revision.
• Integration: helping a customer mount a custom payload (a robotic arm, a LiDAR, a multispectral camera) and making sure the TF tree, power budget, and ROS 2 topics all line up.

The toolchain is what you would expect from a modern mobile robots team: Ubuntu with ROS 2 Humble, Docker for reproducible environments, Git and GitHub Actions for CI, KiCad for electronics, and a mix of FreeCAD and commercial CAD for mechanical parts. Simulation happens in Gazebo, which lets us test navigation behaviors without burning through battery packs.

What “deep work” actually means in robotics

Deep work in robotics rarely means writing code in isolation. More often, it means reading sensor logs, plotting odometry drift in PlotJuggler, and trying to reproduce a bug that only appears when the rover is on uneven terrain with a specific firmware version. A robotics engineer spends a surprising amount of time being a detective: the question is not “what should this code do” but “what did this hardware actually do at 14:32:07 yesterday.”

How field testing fits into the day

No simulation replaces a real outdoor test. At Fictionlab, field testing is not a separate phase done by a separate team; it is part of the engineering loop. Most weeks include at least one session of taking a Leo Rover or Raph Rover outside, usually to a gravel lot, a grassy slope, or a wooded path near the office.

A typical field session looks like this:

1. Flash the latest firmware and software image onto the test unit.
2. Pack spare batteries, a laptop, a router, and (always) duct tape.
3. Drive predefined courses while recording rosbags of IMU, wheel odometry, GPS, and camera data.
4. Note anything weird: a wheel slipping, a Wi-Fi dropout, a thermal warning from the motor controller.
5. Return to the office, replay the rosbag, and turn the observations into issues or pull requests.

Field robotics teaches humility quickly. A controller that behaves perfectly on a flat warehouse floor can oscillate badly on wet grass. A camera exposure that looks fine in the lab can blow out completely under direct sunlight. These lessons only come from going outside, and they are the reason our rovers ship with the defaults they do.

What we have learned from years of outdoor testing

A few patterns repeat often enough that they have shaped how the team works:

• Cable management is a feature. A loose connector found in the field costs an order of magnitude more time than one caught at the bench.
• Logs are cheap, regrets are expensive. Recording everything during a test is almost free; trying to reproduce a one-off failure is not.
• Small payload changes affect dynamics. Adding a robotic arm or a heavy sensor shifts the center of mass and changes how the rover behaves on slopes, which is something we flag for every custom build through our custom robotics service.

What the afternoon brings: customers, community, and code review

Afternoons at Fictionlab are usually more collaborative. This is when calls with B2B customers happen, when pull requests get reviewed, and when the team syncs on roadmap items. Because Leo Rover is used heavily in education and research, we also spend time answering questions on the community forum and reviewing contributions from users who have extended the platform in interesting ways: adding ROS 2 drivers for new sensors, porting the stack to a different SBC, or building entirely new behaviors on top.

Code review in a robotics team has its own rhythm. A reviewer is not just checking style and logic; they are also asking: “Will this run on the actual hardware? What happens if the IMU drops out? Is the QoS profile on this topic correct for a wireless link?” These questions are easy to forget when you are deep in a feature, which is why peer review matters more here than in many pure-software contexts.

How research, education, and community work shape the product

A meaningful share of feedback that drives the roadmap comes from universities and research groups. When a lab uses a Leo Rover to teach a graduate course on SLAM, they find rough edges that a small internal team never would. When a research group uses Raph Rover for outdoor autonomy experiments, they push the platform in ways that reveal what the next hardware revision needs. This loop between product, research, and education is one of the reasons the team values open source: it turns users into collaborators. You can read more about how the team is organized on the Fictionlab about page.

What skills actually matter for a robotics engineer in this kind of role

Job postings tend to list a long stack of technologies. In practice, the skills that make a robotics engineer effective at a small mobile robots company are a bit different from what the bullet points suggest. Based on what the team uses day to day, the short list looks like this:

• Solid ROS 2 fundamentals: nodes, topics, services, actions, TF, lifecycle, and at least a working knowledge of DDS and QoS.
• Linux comfort: systemd, networking, SSH, and the ability to debug a headless robot over a flaky connection.
• Embedded basics: reading a schematic, using an oscilloscope, and understanding why a brownout looks like a software bug.
• Mechanical intuition: you do not need to be a mechanical engineer, but knowing why a part flexes or a wheel slips helps a lot.
• Writing skills: documentation, issue descriptions, and customer emails are part of the job.

The less tangible skill, and arguably the most important, is being comfortable with uncertainty. Robotics problems often do not have a clean answer; they have a best-current-guess that gets refined with the next test. Engineers who enjoy that loop tend to thrive in this kind of work.

What a “good day” looks like

A good day is rarely the day a big feature ships. More often, it is the day a long-standing bug finally reproduces reliably, or the day a customer sends a video of their Leo Rover doing something the team never planned for. It is the day the new firmware passes a two-hour outdoor run without a single warning in the logs. These small wins compound, and over months they are what move a mobile robot platform from “works in the lab” to “works in the field, for years, in the hands of strangers.”

FAQ

What does a robotics engineer at Fictionlab actually work on?

A mix of ROS 2 software, embedded firmware, mechanical and electrical design, field testing, and customer integration work for Leo Rover and Raph Rover platforms.

Do you need a PhD to work in mobile robotics?

No. Strong fundamentals in Linux, ROS 2, and embedded systems, combined with hands-on project experience, matter more than a specific degree. Research backgrounds are valuable but not required.

How much of the work is software versus hardware?

It depends on the engineer’s focus, but most team members touch both during any given week. A typical split might be 60-70% software and 30-40% hardware or mechanical work, with field testing on top.

What ROS 2 distribution does the team use?

A stable target for Leo Rover and Raph Rover work is ROS 2 Humble on Ubuntu 22.04, with newer LTS releases such as ROS 2 Jazzy on Ubuntu 24.04 tracked and validated as needed.

How often does the team do field testing?

In active development sprints, at least once a week. Around a release, daily outdoor tests are common because indoor results rarely match outdoor behavior.

What is the hardest part of the job?

Debugging issues that only appear in specific real-world conditions, such as a particular terrain, temperature, or wireless environment. Reproducing them is often harder than fixing them.

Is the work mostly individual or collaborative?

Both. Mornings tend to be deep individual work; afternoons skew toward reviews, calls, and pairing. Field tests are almost always done in pairs for safety and faster iteration.

Curious about joining the team?

If building open-source mobile robots, debugging ROS 2 stacks, and spending real time outdoors with real hardware sounds like the kind of work worth doing, take a look at the Fictionlab about page to learn more about the team and current opportunities.