Customer is #1
The very first mistake we did is that we didn't talked to the customer. Jason the leader was out of office, but I bet Jason the customer would be behind the corner if we ask for him.
We were creating design and solution without even knowing what the required specs might be. For example in scrum at the meettings the domain expert must be present at all times. Basicaly making sure that the customer is in the loop about all the features and decisions.
So our solution might be valid, but for different problem, because the specs might be different. This might not be as huge mistake, because Jason the customer is allowing lot of freedom for us, but still we need to know the must have features we need to deliver no matter what.
I seen this in multiple teams so this is not problem of this group, I think it's problem in general. I would blame testosterone because I seen in only from male group members. Words like "that's easy", "that's just...." shouldn't be allowed to say in these meetings. Confident statements are great, if you have skill and experience to back it up and deliver, but the problem is that more often it is not delivered. In my last group project over the summer the idea was have a BB8 clone style robot. We were handful of people, 2 months of time metting once a week. While I was trying to simplify and shrink the scope from 4 motor solution into 2 motor solution with basic movement. And have as common to existing easy to finish projects as possible. Others with minimal SW and HW skills were proposing
- that it's easy to make it self balancing robot.
- It's easy to salvage Bluetooth modules from broken phones to communicate between the moving parts.
- make the ball 1m big, it's easy and go big or go home.
- It's easy to use magnets all around the whole diameter (without budged to source them or even clue that it might be lot magnets involved and better mechanical solution to that problem existed which didn't involved magnets)
Of course the project failed. And over the decade of listening to these empty statements I grown allergy to them. It's the beginners pitfall to underestimate the problematic areas. We should stay realistic and stating how XYZ is easy will not help. Even simple things can become problematic and time consuming when we will have to really implement it.
I was guessing what are the really MUST have features for this project. And without any of these the project completely fails.
- Computer vision
- Mechanics of the lamp
- possibly multiple lamps
- Servo sound (is the 3rd year project so with might not worry about it as much, but we need to make it work together anyway)
- RTOS and mbed
- IPC - structures between the threads
- Communication between the lamps (CAN ?)
- Communication with the 3rd year project (CAN ?)
As stated the communication might not take a lot to figure out, yet it's core feature, without the thing will not work.
Then we had lot of additional features, I would recon to be very careful if there is a additional feature which might affect the core features a lot and there is risk of breaking the core feature.
More or less I didn't had any strong feelings either way. Only thing I noticed we sometimes were talking about 2 different things at the same time. Probably we will need to more verbose. "Sound" feature should be split.
- Servo sounds
- Sounds output (additional sounds, not just the servo sounds)
- Sound input (acting to claps and loud noises)
- Sound voice input (voice recognition)
From my personal observation people don't like the RTOS as much. Completely ignoring and underestimating the RTOS part. I completely diasgre with the statements I heard "just copy & paste" or "just put the threads into main". Having many different chefs in the kitchen is bad, but when none of them can't cook properly even worse. I don't want to do system architecture overkill, probably no unit tests, or no static code analysis. But we need bit of structure and a free for all "everybody just make their threads and put it together" is in my eyes is asking for disaster. Somebody will make everybody threads might work well and then somebody will make ISR with long while loop and it will break everything. I think without managing the RTOS part it will be mess when everybody will do anything.
We might need put more effort into RTOS and not just have it as last feature on bottom of each group.
Still I think if some feature will require to give instructions to the users, it will lose the first impression and lot of wow effect we want.
I couldn't finish my proposal and then I was derailed and catched in some details of completely different tangent. My temptation was to decide, servos or steppers.
- Might more precise, steppers allow half and quater steps.
- Continuous rotation while keeping accuracy of each step
- With gears allowing enough torque and even better accuracy, very smooth motion.
- Full control of the speed of the motors compared to servos.
- With belts allowing to have motors down in base, and because no matter what angle the distance of doesn't changes it would be possible to have both heavy motors in the base to leave the arm of the lamp lightweight
- 3D printing boom offers good sources of, pulleys, belts, idlers, motor choices, driver circuits
- Something new which is not rehearsed as much as servos.
- Belt tension is very important in this setup
- Possibility of missing steps if we are not careful about the torque or tension of the belt.
- Some added mechanical complexity, but some mechanical aspects are simplified so not sure if it's harder to make, it's different approach.
My reasoning to talk about it now, was to decide now, because "just do milestones" will not work on this one, we will have to stick with the decision and later might be too late to change.
Core XY 3d printers show that with pulleys and you can do a lot of stuff while the motors are remote. Still offers good load capabilities and are able to move heavy 1kg heads with one or more extruder motors together together with the hotends. So this approach can handle heavy loads, but because the motors are remote the load is bit lighter (lamp would stay balanced with the springs as it is) and the movement even more accurate.
We would have as convoluted setup as CoreXY, but it shows you can do a lot with pulleys and physics