Building an inexpensive (as close to free as possible) workstation based on the Raspberry Pi 3
To make the experience fit your profile, pick a username and tell us what interests you.
On paper the project seems plausible, how about in reality? This is the job for the demonstrator: a demonstration unit of the final product. It doesn't have to be necessarily made from the final components or use the final production method, but it shows that we have indeed the know-how, skills and parts that fit together and work.
This is absolutely necessary as very often parts of a project are easy to make/implement, but when it comes to making everything work together it all falls down. A demonstrator is the ultimate proof that the project is not just hot air, if investors were involved they would start throwing money at this stage of the project.
In the spirit of Hackaday we decided to strip the screen open and look for a 5V supply, who knows we may stumble upon one and lower the unit cost by removing the supply for the Raspberry Pi.
The first idea was to tap the VGA port, indeed it has 5V on one of the pins, Hackaday has even featured a project doing exactly that. However 300mA to 1A output is not specific enough, it has to guarantee the current the Raspberry Pi, and its peripherals, need (a minimum of 1A to be sure).
On the bottom there was an audio board, this looked really promising...
There was a LM2596S chip, stepping down 17V to 10V for the speakers. By poking around with a multimeter it was found out that the manufacturer used the adjustable output voltage circuit described on the page 9 of the part datasheet which allows to adjust the output voltage via resistors.
After some calculations to make sure the output would satisfy the Raspberry Pi power needs and a trip to the local robotics club to get the right resistors it was time to carefully solder them on.
The hack was successful, the output voltage was slightly above 5V and Raspbian Jessie booted up.
Here's how to use a 20" screen to power a Raspberry Pi (we didn't have a HDMI to DVI converter at the time).
However, when we tested the speakers, using a male-to-male jack cable, there was a constant high pitched noise, it was either due to the fact that we provided 5V to the audio system instead of 10V or that the power going to the Raspberry Pi was so noisy it induced noise in the audio output. Since disconnecting the audio cable made the thing quiet again it was probably the noise on the 5V line... this was not good at all.
In the end it was decided to abandon the idea of using the screen to power the Raspberry Pi, indeed we do not have complete understanding of what we were dealing with and if it needs to be reliable and robust then cutting such corners might simply be unproductive.
The second milestone is all about finalising the project and making sure we are realistic in the functional, financial and timely aspects. We're always working with the goal in mind: cheap computers for Malawi orphanage, how we get there is just a necessity and the procedure needs to be efficient.
Things in bold have changed since the original functional specifications.
One station will cost $62 and weigh about 8.5Kg. To this must be added the transport costs with add another $100, so total cost is $286 for three systems as the weight limit is 28Kg. With this system we achieve 25% of maximum fitness.
Gantt chart has not changed since last time. The second milestone log is late, however the project itself is well within limits and going strong.
The very final part of the first milestone is to plan the project schedule, for this we use something called a Gantt chart. This fixes development progress deadlines using subjective time allocation (better than nothing), task linkage and allows to see the critical path. Indeed some tasks depend on others, if something takes longer than expected then it will delay all the tasks that depend on it, these tasks are critical, thus the critical path.
With a Gantt chart it is easy to understand what are the important tasks that should be focused on and what to leave for later. The Gantt chart should be opened at all times, checked regularly by all members working on the project and updated by the project manager.
You can make a project schedule using free tools such as Gantter.
In the current project nothing can be done in parallel, I admit it's not a very good example of Gantt chart application. The demonstrator can only be built when the needs, functions, etc. are done, it doesn't make any sense to jump to solutions if you don't have a good idea of what you actually need (do not confuse with "want"). Often I notice people looking for solutions for non-existing problems, that's just inefficient, usually waste of time and shows incapacity in proper project management, somebody mentioning a solution before a project has started is already a red flag (but so much more fun).
With this schedule the computers are going to be ready just in time before the departure to Malawi. Following it (and updating it often) allows to concentrate man-hours where needed and has a high probability of getting it finished within the deadline.
Selecting the best objective solution is not always easy, let's face it, we want to mess with a Raspberry Pi. This project is not about doing what we want though (see the five W and the needs), so if in the end the selected solution does not meet the functional specifications in a satisfying way and there is a better alternative then the workstation is going to be discarded in favour of the better solution.
That being said, we select the Raspberry Pi 3 workstation as the best objective solution.
The university we work at has a computer recycling program, the people managing this program were kind enough to provide five 20" screens with integrated speakers (Philips Brilliance 200P4SS/00), mouses and keyboards for free for the cause. However even though the screens are flat they are very heavy: about 7.5Kg per screen.
So the current cost of one computer:
Total: $62 per workstation.
For the weight budget:
Total: 8.5Kg per workstation.
According to our previous formula:
That's a decent dollar to computer ratio of about 100 and will cost about $300 total. It's not the $50 and 3Kg per computer we hoped for, but it's good enough and yields about 0.1/0.25 of the global performance (40% of maximum performance) - see the Transport Costs log.
It's also important to mention that at this point the problem of intermittent power failures that can corrupt the RPi filesystem is not yet solved, an UPS is an expensive element, but there are other ways to mitigate this issue.
We still do not have a good overview of what the total cost from buying to delivery to Malawi is, so in order to make the best objective solution we need to obtain these numbers.
Weight per computer is one of the most important ratios to consider here: personal items take out a big portion of the weight budget and it is not negotiable, so it does not leave a lot for the computers, a second baggage might be necessary, but it's expensive. Let's break it down using approximate numbers:
Essentially what we want are magical free computers that do not weigh anything. Of course there are volume limits as well, but they are too difficult to specify as of now.
The maximum number of computers goes like this:
Where c represents the number of computers, p the price of a computer, w the weight of a computer, B the total budget, Wp the price of an additional baggage and W1 the allowable weight using a single bag and W2 the weight allowed in an additional bag.
Another way to represent it is with a graph using the two variables: price and weight:
This is great, however we are still interested how much computer per buck we can get. This next figure shows the total cost instead of the number of computers:
Finally to get the best bang for buck we are going to divide the normalised computers and cost values together (number of computers / dollar) to get the "performance":
Now that's some sexy data. We see a peak around $50 and 3Kg, which yields about 9 computers. Weight doesn't seem to make much difference, unless the computers are really cheap. Another interesting aspect is that the maximum achievable performance is only 25% of the true maximum performance, this is due to the fact that the best price and optimal weight point are never coincident.
Let's iterate the hardware functional specifications and enter those new values. Lucky us: the potential solutions do not change.
The needs defined the basic foundations of the project, the functions defined the project requirements and the functional specifications quantified the functions. Now is the time to come up with solutions by way of brainstorming, far fetched ideas can often trigger more realistic potential solutions, so anything goes:
In this non-exhaustive list of solutions there are obvious bad ones which are immediately filtered for good reasons:
This leaves the Raspberry Pi, laptop and tablet as realistic solutions. They all have advantages and disadvantages:
We now have a choice between three somewhat objective solutions, however to select one of them we need to look at the total cost of what it takes to buy and transport them to Malawi...
The functions list is a good start and gives an excellent overview of what we want to achieve, however qualifiers like "cheap" and "robust" are not explicit enough to efficiently translate them to solutions yet. So the next task is to make the list of functional specifications. Take the functions list and add proper quantifiers or explanations as much as possible:
This is the list that might change the most during the project development. If somebody offers to transport the goods for free then we might up the weight limit, if the solution provides its own backup system in case of power loss we might even remove this function...
We are slowly approaching the final steps of the first milestone. We know our needs and what functions the project must fill and now we have quantified the quantifiable. It is finally time to start brainstorming about the possible solutions.
The milestone 1 is all about properly specifying the project goals, it's quite a big task so I'll divide it in several project logs.
Using the list of needs developed for milestone 0 it is time to make the list of functions. Functions are what the project must have, be or do. We are going to divide the functions into internal (software) and external (hardware) functions. Dividing tasks to smaller bits allows to focus better and make relatively objective decisions.
List of project functions:
This list is slightly more mutable than the needs list, we are probably going to come back to it later. But this allows us to see what the project is really about.
To the functions list we can add a list of nice to have functions. This list contains more subjective things, but will only be considered when all the must have functions are satisfied and the nice to have functions shall not have any financial or time impact on the project.
List of nice to have functions:
We now have a good foundation which we use in all future decisions, this will allow to cut down drastically on the project iterations and thus time and money.
Let's go over the standard product development routine. Here it's not really a product that we are developing, however this method allows to select the best objective solution for the task at hand.
The first milestone, actually called "milestone zero", consists in listing the needs in the form of: <verb> <noun>, as much as possible. In the case of computers for the staff of an orphanage in Malawi (in no particular order):
These needs are invariant throughout the project, contrary to the project features (which are an engineer's nightmare as the some project managers change them in function of the room temperature). It is still important to come back to the needs list from time to time and make sure it is indeed what is needed, as the first draft is usually not the final. For example if it turns out they run their systems on generators then the "Survive power outages" could be removed and that will make the work that much easier.
The needs will have to be satisfied by the selected solution later, but first they have to be put in a more readable form and quantified, so the next task is to list the functions of the project.
A word on the background of this project to understand the five W's: who, what, where, when, why.
My friend is a qualified engineer knowing his way around electronics, software and mechanical stuff. From C language programming to designing a part for 3D printing, passing by PCB and electronics design, these things do not hold any secrets from him anymore. He would nicely fit into the Hackaday community, but he's not very present on the Internet, so I'm writing this on his behalf.
An orphanage in Malawi is having trouble keeping up with the administrative paperwork. The orphanage has about 150 children for 20 staff members. The current administrative work is done on paper, a picture is taken of that paper and is sent wherever it needs to be sent. This is not efficient and they want to use computers to be more productive.
The staff hardly speaks any English and do not know how to use computers very well, so they need computers, somebody to instruct them how to turn them on, show how to use basic office tools and perhaps a translator. The computers and transport costs are all on behalf of my friend.
In May 2016, during 3 weeks.
GDP-wise Malawi it's one of the poorest countries in the world (in the bottom 3, depending on the year). There are a lot of orphans in Malawi and an efficient management may allow for a better care for them or to accept more orphans per staff member.
Become a member to follow this project and never miss any updates