What does a "Robotics Software Engineer" do?

[Yousof Ebneddin]

I am wondering what a "Robotics Software Engineer" might do in a company. What are the responsibilities? What is the role about? I understand that it highly depends on the company and the team but I would like to learn more about this kind of roles. Thanks.

[camp .]

    Robotics is an interdisciplinary activity. It involves mechanics, electronics, and software. Each discipline is its own field of study. The "Robotics Software Engineer" creates software that actuates motors and monitors sensors to create desired behaviors. The most common programming languages are C++, Python, and Java. Linux is arguably the most popular operating system for robotics, but bare-metal embedded programming is also common.

    Software is typically developed on GitHub, which can be made private. You might create new software or test, improve, or debug current software. The synergistic effect of engineers working together in their respective areas of expertise results in an effort greater than the sum of its parts.

 

- Camp

On Thursday, November 18, 2021, 08:05:25 PM EST, Yousof Ebneddin <youe...@gmail.com> wrote:

I am wondering what a "Robotics Software Engineer" might do in a company. What are the responsibilities? What is the role about? I understand that it highly depends on the company and the team but I would like to learn more about this kind of roles. Thanks.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/9ae78e93-e808-4568-9c89-82237b1d6ae8n%40googlegroups.com.

[Yousof Ebneddin]

Hi camp, Thanks

Do you have specific examples?

[Yousof Ebneddin]

I did the Udacity's Robotics Nanodegree and I really hated it. It was only writing launch files for ROS and there were very minimum Cpp programming, I am just wondering if that is really robotics software engineering? How much of algorithm development is required in a robotics software engineering?

[Michael Wimble]

It kind of depends on your role and your project. For hobby robots, you probably won’t get into writing low level planners or localization algorithms , but if you do, themath is heavy and the coding task is large. 

If your writing a fetch me a beer bot, most of your coding will likely be in device drivers and behavior algorithms, with a large dose of configuration of packaged software. 

If your writing a table bot, it’s all coding but probably only a few hundreds or thousands of lines. 

For industrial robots, the task is so big that you will specialize in one area, even tiny areas of AI algorithms like predicting the  behavior  of  a single kind of tracked object. 

It’s up to you to decide how much of the chunk of the problem you want to tackle.

If you plan to use ROS, expect to read a lot more code than you read the documentation. It’s a lot of stuff to know before things work well for the right reasons. None if the planners or SLAM packages work well out of the box. 

Everything about robots is hard. 

On Nov 21, 2021, at 11:58 AM, Yousof Ebneddin <youe...@gmail.com> wrote:

I did the Udacity's Robotics Nanodegree and I really hated it. It was only writing launch files for ROS and there were very minimum Cpp programming, I am just wondering if that is really robotics software engineering? How much of algorithm development is required in a robotics software engineering?

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/760490e0-50d0-4554-b9e9-2057a06972bdn%40googlegroups.com.

[camp .]

    I'd say the best strategy is to build stuff and let your robots do the talking. Mobile robotics is a blank canvas, so you'll find yourself on the cutting edge very fast. I'm basically a sales guy who has to build the robots before he can sell them. Regardless, before working at Neato, I'd always considered robot-building as kind of a solitary endeavor. It was there I realized the synergistic effect of experts in their specific domains. Contrary to popular belief, not everyone is a mechanical engineer.

 

- Camp

https://groups.google.com/d/msgid/hbrobotics/ea281f13-7b63-4849-9913-f6b4ae6bc8ffn%40googlegroups.com

.

[Sampsa Ranta]

Yeah,

when you go to academic side of robotics, it's split into even more fine grained fields than previously mentioned. For example computer vision (extracting features, optical flow and stuff), control theory (linear and non-linear control, PID, etc), the mechanics, the electronics and kinematics are quite separate tracks. Depends how deep you want dive into individual fields. But that's also a bit dull side of the academics, typically when you go higher up, you focus on single thing. And robots are about combining it all.

For practical sie, there are different approaches. If you take ROS components, say the Nav2 stack Camp likes to work on .. from my perspective, I say this can be considered more of an a integration task and getting the parameters right. But this requires you spend some time figuring what makes the existing framework tick, and putting it into use. And when you understand how the existing stuff works, maybe you improve it if needed.

The other way around is the NIH syndrome approach. NIH stands for "not invented here", and for the typical syndrome symptoms is that non-NIH solution is not acceptable. This is the hard way and might not provide fast forward method into advanced topics.

For the embedded side, you often figure there is a balance between how much computing power due to also limited power supply. If you want to do more onboard, you need a bigger heavier robot. Or then you need to figure the engineering trick how to do it optimized way if such exists.

For the easily available educational side, I suggest try few of Duckietown videos. I think they have new MOOC coming soon. They have ROS flavouring, Python stuff, robot platform with simulator-to-real concepts and stuff. Even simulated robotics was interesting on this platform. https://www.facebook.com/duckietown

I often like platforms and groups that have a supportive community.

- Sampsa

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/391329040.3411524.1637298584453%40mail.yahoo.com.

[Pito Salas]

Thanks. This was  a great and useful thread. 

Pito Salas
Faculty, Computer Science
Brandeis University

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CAOF2Wg6znmLTikRrGs-Qrf6d_oLB7ftuBmEfcfSeE1EW7pkTwQ%40mail.gmail.com.

[Alan Federman]

for most of my career, my official title was software engineer. I'd estimate the amount of actual coding I did was 5 to 10% of the time. Especially doing robotics work, I estimate 50% of the time is systems analysis, OS upgrades and maintenance, 25% hardware, 20% overhead, paperwork, meetings documentation. 

Here are some of the issues I've dealt with recently, as I am integrating a new sensor and a system upgrade.

Robot not moving - Battery unplugged, charger attached.

Robot not booting - battery low, 5v circuit undervolt

Sensor not displaying data - comments left in ymal launch parameters.

Sensor not working - proper interface driver not installed.

new lidar added - needed to get driver from GitHub, catkin_make, URDF made.

Steve Ciaciara(sp?) a famous computer engineer, was once asked what his favorite programming language was. His answer: "Solder." I think that being an expert in any very specific but esoteric fad software of the day is a bad idea. Not a lot of call for Cobol, Pascal, or Ada programmers out there. more recently all the time I spent honing my Perl and PHP skills aren't relevant. What is relevant is living at the Unix (Ubuntu) CLI, and being able to get in and see what's going on in your robot from a terminal. If you want to get into robotics, and 

 have limited resources, the easiest way is to become a member or a mentor of a HS competition team. There's FIRST, Botball, Vex among others, now there is a underwater robot competition, and I would be surprised if drones aren't included somewhere. Besides the engineering side, the soft team building skills are equally important. Robotics is definitely a team sport. 

If you are totally isolated, and want to get into Robotics, you can go virtual. There are ROS images for Jetson and Raspberry Pi. if you are reading this, you already have found a good place to start.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/8CFD8187-59D4-4608-B1D3-8A74A646F435%40gmail.com.

[Yousof Ebneddin]

What about "Robotics Research Engineer"? Have you had experience with such title?

[Michael Ferguson]

I think all of this is highly dependent on the size and type of the company you are joining.

In an early stage startup, the whole "robotics" team might be only a few people - in that case, yes, a Robotics Software Engineer will be jumping around all over the place from low level drivers, high level planning, computer vision, etc - whatever needs to get done. They will also spend a large portion of their time doing system debugging and devops (system updates, buildfarm maintenance, etc).

Regardless of team size, at most places that have more than 2-3 engineers, there will be a separate hardware team that actually designs the mechanical and electrical structure of the robot - and unless you are extremely experienced in whole robot design you would likely not be part of both teams.

As the size of the team grows, people often become more specialized. You'll find that engineering teams larger than 10-20 people usually have a separate Devops team that handles deployment. Usually they have a separate test team as well. Often these companies will have a dedicated person/team who deals with firmware/drivers. That frees up the "robotics" team to focus on things like localization, planning, perception, sensor filtering, etc. As the team gets even larger you often end up with separate teams of specialized people dedicated to just localization, perception, or planning.

The type of company also matters quite a bit. All of my above is based on companies building modern AMRs (autonomous mobile robots) or picking robots (for example, Fetch, Clearpath, Righthand). If the company is more of an integrator or AGV company, then their idea of "software" may actually be very basic programming using something like the teach pendant of an industrial robot (you can usually figure this out quickly because instead of asking for Python/C++/ROS, they are looking for PLC or other experience in the job posting).

Regardless of team size, robots (and the environments they operate in) are complex, and so at a product company the majority of your software development time ends up being dealing with new uses and edge cases that arrive from field experience, and generally making everything more robust. A very small portion of the time is spent building "greenfield" solutions from scratch. If it is more of a research-oriented organization, you'd probably spend most of your time building prototypes of things and writing papers to share your research, and far less making things robust in all environments (this would be my expectation anywhere that is looking for a "robotics research engineer" - although most places are probably looking for a PhD in robotics for this role - I probably couldn't even land this kind of position due to my limited publication history and lack of a PhD).

-Fergs

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/13d13738-62df-44cf-8495-1ebcfa70795fn%40googlegroups.com.

[Yousof Ebneddin]

Thanks. This was very helpful.