How To Position Yourself For Embedded Software In 5EID0
Question
If you want to tell your teammates that you prefer embedded software and mainly want to do coding, how should you think about it?
Short Answer
That preference is valid.
The manual explicitly lists embedded software as one of the course specializations and defines it as developing C/C++ code for the Pynq board to control the robot and its sensors/actuators.
Good Positioning
The strongest way to present yourself is not:
- “I only want to code”
but rather:
- “I want to take primary responsibility for embedded software, robot-side control, and sensor/actuator integration.”
That sounds stronger because it is:
- aligned with the official specialization
- concrete
- useful to the team
- still compatible with team-level responsibilities
What You Should Be Ready To Own
If you take the embedded-software role seriously, you should expect to contribute to:
- robot-side
C/C++control logic - sensor/actuator interfacing on the Pynq board
- integration with communication and higher-level algorithms
- test plans for the embedded part
- reporting your subsystem clearly in the design/final report
Important Warning
Do not frame it as:
- “I only do coding, not reports, planning, or design”
because the course grading clearly requires:
- contribution to the engineering process
- system understanding
- individual reflection on technical contribution and teamwork
So your specialization can be narrow, but your course responsibility cannot be narrow.
Practical Recommendation
Tell your group something like:
I would like to take the embedded software role, especially robot-side C/C++ coding on the Pynq board, sensor/actuator control, and integration on the robot itself. I can take primary ownership there, while still helping with testing and reporting for that subsystem.
That is much stronger than simply saying “I want to do coding.”
Team-Sheet Note
From the provided Teams.xlsx, the user appears to be in:
- team
28 - group
D - room
Neuron 0.232
Counterpoints and Gaps
- specialization preference does not guarantee that teammates will accept the split automatically
- embedded software in this course may overlap with algorithms and communication, so boundaries need to be negotiated clearly inside the team