Computer Software Vs Embedded Software In 5EID0
Question
For Vipin, which is more beneficial in the 5EID0 project course: computer software and user interface or embedded software?
Updated Decision
Vipin has decided to take the computer software and user interface role.
See 2026-04-22-computer-software-ui-role-plan-for-5eid0 for the execution plan.
Earlier Comparison
Embedded software is probably more beneficial for Vipin if the goal is to build stronger coding credibility inside an electrical-engineering robotics project.
But the safest position is not pure embedded-only.
The best role is:
- primary: embedded software
- secondary: robot-to-base-station data interface / MQTT integration
This gives both low-level technical depth and visible system-level impact.
Comparison
| Dimension | Embedded software | Computer software / UI |
|---|---|---|
| Course relevance | Very central; robot autonomy depends on it | Also important; map and base-station output depend on it |
| Technical depth | Higher hardware/software integration depth | Higher user-facing/product visibility |
| Coding profile | C/C++, Pynq, sensors, actuators, robot control | Python/JS/GUI/data visualization/MQTT dashboard |
| Risk | Higher, because hardware integration can be painful | Lower to medium, easier to iterate on laptop |
| Demo visibility | Indirect but mission-critical | Very visible in video/report |
| Report value | Strong if tests and integration are documented | Strong if screenshots and map evolution are clear |
| Long-term EE value | Stronger for embedded/robotics credibility | Stronger for software/product/UI credibility |
Why Embedded Software Is Better For Vipin
The manual explicitly defines embedded software as:
C/C++code for the Pynq board- controlling robot sensors and actuators
That role is closer to:
- robotics
- hardware/software integration
- autonomous system behavior
- electrical-engineering project credibility
If Vipin wants to tell teammates “I want to do coding”, embedded software makes that coding more central to the physical system.
The Main Risk
Embedded software can become invisible if it is not documented well.
For example, if the robot works, people may only see:
- it moves
- it detects objects
- it avoids cliffs
They may not notice how much robot-side code made that possible.
So the embedded role needs evidence:
- subsystem diagram
- interface definition
- test logs
- integration notes
- demo scenes showing robot behavior
- final report section explaining the embedded logic
Why Computer Software/UI Is Still Attractive
Computer software and UI can be easier to show:
- map on screen
- MQTT data display
- visualization of rocks, cliffs, mountains, and explored area
This makes it very visible in the demo video and final report.
It is also less blocked by hardware problems because much of it can be developed and tested on a laptop.
Recommended Positioning
Vipin should not say:
I only want embedded software and nothing else.
Better:
I would like to take primary responsibility for embedded software on the robot side, especially C/C++ control on the Pynq board, sensor/actuator integration, and making sure the robot can send clean data to the base station. I can also coordinate with whoever does the computer software/UI so our data format and MQTT messages match.
This is strong because it:
- claims a clear technical role
- connects embedded work to the full system
- avoids sounding narrow
- creates visible integration value
Practical Decision
If forced to choose one:
- choose
embedded software
If allowed to shape the role:
- choose
embedded software + MQTT/data interface to computer software
That is the best balance of coding, course relevance, and visible contribution.
Counterpoints and Gaps
- if the team already has several strong embedded people, taking computer software/UI may give Vipin more ownership and visibility
- if hardware access is limited or unstable, UI/software may be a safer way to deliver working output
- final role choice should depend on teammates’ preferences and skill distribution