To give some reflections on the locker let us look at what went well and what could have been done better, or serve as things to remember for future projects.
First of all, we can conclude that it was a good idea to have the electronics mounted on the static part of the locker (not the door) since there otherwise easily could have been some problems with squeezing the cables which is not ideal for any construction. This will definitely something that is smart to remember further on. We could still have optimized the cable from the button a bit more, by hiding it better but overall the amount of cable clutter is kept to a minimum. This is primarily also due to our protection box for the hardware.
Even though we kept trying to think the solution to an end, and avoid problems it is still very hard to predict everything that comes up. We especially had problems with the code and could not seem to figure out why. We could perhaps have made a more thought through solution for the mounting of components, some of the other groups have made 3d printed holders for their components which gives a very finished look. I will say though that the way we worked with the placing of components was very flexible if anything where to go wrong. Since we were developing software, hardware and design parallel to each other it would have been difficult to decide specifics mounting spots for the components if we would come up with some changes to these. So looking back it has been quite favorable to have such a flexible approach to the mounting of components because this made sure we didn’t close down opportunities in the developement. The downside is though that it is not very optimal for mass production – but you can’t have everything.
Considering the database the structure does not necessarily seem very logical. It was at least not clear to us why asking the database about the scanned serial number being in the database had to be the first question in the diagram. This probably all comes down to the fact that we have nothing to do with the mothership (we cannot model it directly) and sometimes this can feel like groping in the dark. There are some aspects in the project that are just given to us, because we are have other learning objectives but this can give a feeling of the easy way out. Or maybe even like we have not learnt everything to the full extend. But again it is a balance, this time between digging into some knowledge and becoming experts on subjects or otherwise knowing a little bit about a lot of things. Which is a quality that is actually very important for us as design engineers since the ability to understand new problems quickly is highly valuable if we have to tackle a huge variety of problems.
Something that has worked a little bit against this “knowing a little about many things” is the work distribution that we have had in the group. In a larger scale than the former project we have worked more split up. Since there are so many things to account for in this project it would not make sence to all work at one thing everyone together – it would simply be inefficient. This results in that not all of us have learnt the same things, but again it is a balance. We have simply not had the time to all get to know everything in the project.
To point out something that could definitely have been done better it was the planning of the project. The planning of when to work on the project has been done as we went on. This is mainly due to the amount of different courses we all have, all with other group works to schedule. Anyhow this we will take into account on our next project and maybe create a timetable or gant chart. Of course the pressure from other courses will luckily not be present.
Some function we wanted to incorporate, for instance sending an email to the user of the locker but we could not assign to the json object in NodeRED and therefore had to not go through whit the idea.