The Electronics Design Project is a EEE2 and EIE2 module that runs in the Summer Term. It begins with a breifing, which follows the final written exam in May, and it ends with a demo and interview assessment near the end of the term. Students work in groups of six to design and implement a system that meets some high-level objectives. There is a choice of three topics for the project.
Most of the study time for the project is self-organised. You will need to plan your work from requirement elaboration and design decision exploration through to system integration and documentation. A series of talks is organised to help you with non-technical aspects.
Project groups may be self-selected. Your group must contain at least two students from the EEE programme and two from the EIE programme. You may register a group of four, five or six members, but if you register fewer than six members it is possible that others will be added to your group. It is also possible that groups of four will be broken up if there is no-one available to join the group. There may be some groups of five due to division of the cohort.
Each project option can only support a limited number of groups, so you will need to rank your option preferences. If an option is oversubscribed for first preferences, then some groups will be allocated to their second choice.
If you do not have a self-selected group then you may also submit preferences as an individual, which will be considered when allocating you to a group.
All three projects share some common aims. They all require the design and implementation of a system made up of modular elements and interfaces between them. The project topics are designed to draw on different areas of the EEE and EIE curricula, so that a collaborative approach is needed, drawing on different disciplines and skills. Not every challenge in the project will be familiar and you will need to conduct independent research and apply general problem solving techniques to work towards the project requirements. Some solutions may require the specification and purchasing of additional components, for which a budget is provided. Finally, every project will draw upon various non-technical skill areas, including project planning and management, communication and teamworking.
| Weighting of presentation in module mark | 25/100 |
|---|
| Area of assessment | Weighting | High mark | Medium mark | Low mark |
|---|---|---|---|---|
| Requirements Capture | 20/100 | • Original requirements expanded into project-specific requirements • Quantitative specifications given where appropriate • Requirements for subsystems |
• Project requirements are expanded and customised | • Project aims are given, but there is some ambiguity |
| System Design | 30/100 | • Strong reasoning for system design decisions • All blocks and interfaces defined |
• Core elements of the system are defined • The system design is mostly plausible |
• Some important blocks or interfaces in the system are undefined • Unreasonable assumptions about how parts of the design will work |
| System Implementation | 30/100 | • Evidence that all system interfaces are implemented, using emulation or placeholder data where necessary • Some implementation of functionality in each subsytem • Some infrastructure is in place for evaluation |
• Some progress on subsystem implementation • Some progress on system interfaces allowing interaction of some subsystems |
• Some sub-system implementation but little attempt at system integration |
| Project Management | 20/100 | • All group member roles are defined • Risks and contingencies identified • Significant contribution of each group member • Project management framework adopted |
• Clear division of work between group members | • Roles of group members are unclear |
| Weighting of report in module mark | 50/100 |
|---|---|
| Word Limit | 10000 |
| Area of assessment | Weighting | High mark | Medium mark | Low mark |
|---|---|---|---|---|
| Design Process | 20/100 | • Logical progression of design from top-level requirements to detailed implementation and evaluation • Discussion of all important design decisions with quantitative and qualitative evidence • Interesting discussion of project planning and organisation |
• Requirements in place for most of the functionality of the system • Discussion of design decisions, but some unclear reasoning and/or unimportant details • Full breakdown of task allocation to group members |
• Some elaboration of requirements beyond original points in project brief • Some discussion of design decisions, but important aspects given trivial or no reasoning |
| Implementation | 55/100 | • Design is a technically complex system of interacting components • Advanced techniques and skills are applied, requiring research beyond module content |
• Design is a mostly-functional system, maybe some elements are not integrated • Design makes good use of EEE/EIE module content |
• Elements of the project are designed, but the project is not functional as a complete system • Some design elements are technically plausible |
| Evaluation | 20/100 | • Evidence that tests all requirements • Evaluation of top-level system and individual subsystems • Appropriate tests and metrics devised • Informative visual presentation of data |
• Evaluation of most requirements • Use of quantitative and qualitative data |
• Some elements of the design are evaluated, but some important aspects are omitted • Low-quality evidence of design outcome |
| Reflection | 5/100 | • Weekly reflection forms are completed | • Weekly reflection forms are not completed |
| Weighting of presentation in module mark | 25/100 |
|---|
| Area of assessment | Weighting | High mark | Medium mark | Low mark |
|---|---|---|---|---|
| Functionality | 30/100 | • The system works very well, with few flaws • The user interaction is intuitive • Some elements are technically astounding |
• Integrated demonstration that shows most elements of the project working together • Demo gives an impression of the overall user interaction |
• Demo of independent elements of the project without complete integration • Demo shows project outcome but leaves viewer confused about which elements work properly • Requests to recompile or reconfigure the system during demo to show different elements |
| Technical Insight | 40/100 | • Detailed reasoning is given for questions about design and implementation • Question responses show complete understanding of technical challenges and solutions • Plausible suggestions for addressing flaws |
• Answers to most questions show understanding of technical details • Justification for most design and implementation decisions • Honest discussion of limitations |
• Elements of the project are demonstrated but there is a dubious explanation about why they work or don't work • Third-party libraries are demonstrated without discussion about their limitations, or how they should be integrated into the system |
| Group working | 30/100 | • Clear role for each group member in the implementation • Each group member makes a strong contribution to question and answer • Interaction of project subsystems shows close cooperation between group members |
• All group members contribute to the discussion • Evidence that group members have collaborated on system integration |
• Some group members don't contribute to the discussion, making their contribution unclear. • Elements of the project are mostly independent from each other, showing a lower amount of cooperation |
Note
Information from the demo may be used to adjust the report mark. For example, this could arise where claims in the report do not match evidence from the demo, or the report did not give a true sense of the complexity of a project element
The three project options are intended to build upon elements of both the EEE and EIE programmes. Each of the project options contains elements that are suited to students from your stream.
Detailed Requirements and Technical Information
The aim of this project is to build a demonstrator robot that can balance on two wheels. You should choose an application for the robot that will demonstrate interaction with human users or the environment. A robot platform is provided, which contains wheels, motors, batteries, power electronics and mounting points for embedded computing platforms
- Use a control algorithm to achieve stability of the robot and allow it to move around the environment
- Add sensing and/or imaging components to the robot that allows it to detect obstacles, users or other objects that are appropriate to the demonstrator environment
- Construct a head unit for the robot that suits its purpose as a demonstrator
- Monitor power consumption and battery status of the robot
- Create a remote user interface that allows manual control of the robot's motion and shows a history of events, plus other information relevant to the demonstrator application
Detailed Requirements and Technical Information
The aim of this project is to build an energy management system for connecting a home to a smart grid. A photovoltaic array and mechanical flywheel are provided for energy generation and storage. The system must balance energy supply and demand and use forecasting to minimise the cost of imported energy from the grid. Some inputs and outputs of the system, such as sunshine intensity, costs of energy and power demand, will vary over a simulated day. These quantities follow established trends but they are not entirely predictable, so decisions (e.g. whether to store or sell excess energy) require modelling to deliver the best expected outcome - this is a similar problem to those faced by stock market traders.
- Develop network-connected power converters, based on the Power Electronics lab hardware, that can control loads and match the differing voltage and current characteristics of the components in the system
- Characterise the PV array and flywheel to ensure efficient energy conversion
- Create a database with a user interface that shows the history, current state and forecast of internal and external variables in the system
- Create a backend service that uses mathematical modelling to make decisions about when to store and use energy
Detailed Requirements and Technical Information
The aim of this project is to create an educational tool that can visualise a mathematical function. Evaluation of the function will be computationally intensive, which means that a custom-logic FPGA accelerator is a good choice for achieving the necessary responsiveness for human interaction. The advantage of FPGA accelerator is that the logic is specific to the algorithm, which makes it more efficient than a CPU implementation. However, maximising the potential of the FPGA requires parallelisation of the algorithm and choosing the best number representations and word lengths. A starter project is provided that demonstrates the interface between a simple video generator and a processor system running Linux on the Zynq platform.
- Develop an accelerator for the Pynq system-on-chip FPGA platform, written in Verilog or SystemVerilog, that can generate a video output visualising the chosen function
- Identify opportunities for parallelism to increase calculation throughput
- Use numerical analysis to determine the optimum number representations and bit-widths to achieve a suitable accuracy
- Use human-computer interaction to allow a user to manipulate and understand the visualisation
- Quantify the impact of design implementation decisions in terms of algorthmic throughput