Week 1-2 (12 to 23 May 2025) – Brainstorming of project idea (Paper recycling machine) and exploration + research + experimentation of necessary methods for the idea, Searching for possible alternative project ideas

We made some experiments to recycle paper at our home and tested out several methods to dry the recycled materials, however, drying time proved to be a challenge for us – hence after exploration we discussed that Electrohydrostatic Drying (EHD) is a possible method to dry the paper in a short amount of time with least wastage of electrical energy. However, after discussion with the facilitators, it turned out to be a safety risk as the method involves use of a high voltage (20kV+). Therefore, we explored alternatives to our project idea. One exploration is a machine similar to a tourbillon; however, we decided to use the time-keeping mechanism of a tourbillon and decided to use in an application where precise time keeping is necessary – infusion / peristaltic pump for medical use.

 

Experiments on recycling paper at home

Brainstorming ideas for drying the recycled paper

Initial sketches discussing the mechanism for infusion pump

---

Week 3 (26 to 30 May 2025) – Researching the materials to buy + Buying of Arduino Nano and relevant materials + Risk Assessment

We researched and discussed what mechanisms and materials would provide the outcome (pumping device) that we want, compiled them and bought the relevant materials at Sim Lim Tower. Throughout the week, we had to compile the job scope involved in this project, assess the possible injuries / harm / risks, and completed the Risk Assessment (RA).

Explored simpler solutions to drive the infusion pumps mechanically:

1. Weights
   Using a recoil anchor escapement mechanism to regulate my timing and accurate flowrate of liquids. Much like those mechanisms in grandfather clocks, we aim to implore this drive our pump. However, the issue with this is pratical enough method for energy storage. using a weight of 1kg to drop a height of 1m would also result in 9.8j of energy.  Comparing with a power efficient motor that uses around an average of 1w of power, we will require 3600j of energy if we aim for the pump to run for 1hr. Even discounting energy lost from the efficiency of the pump, it is clear that weights (or gravitational potential energy) would not provide nearly enough power to drive our pump. 
   
2. Springs
   Using springs to power the pump similarly also does not provide enough power nor energy storage for this application. Even if we want to combine multiple springs or integrate it with weights to increase our total potential energy, it seems unlikely that it would be able to drive the pump well, and for any substanial  amount of time.
   
3. Flywheels
   Imagine fidget spinners, but we harness their rotational KE into something else, in this scenrio, harness it into driving our fluid pumps.
   Flywheels are essentially large, heavy discs of metals that you get into spinning at very fast speeds. However due to inertia, they will take a long time to slow down. In a way, we can think of them as storing potential energy.
   There are multiple methods to draw this energy. One of the most common and simplest methods is attaching magnets to the  flywheel, which then moves around coiled wires, thus causing any induced current.
   Performing the calculations, this flywheel method does seem to provide much more substainial power, and would be viable for the project, at least where it is realistic enough for use. However, the issue with flywheels would be on how to obtain such materials.
   The flywheel could likely be made via CNC aluminum for the desired dimensions. The magnets would need to be purchased.
   However, the main challenge of this would be on getting the flywheel to enough speed to contain the desired energy, without the use of electrical equipment. Likely, we will need to attached the flywheels to a bicycle that would allow for the desired energy. However, adapting this would be very difficult without further making more CNC aluminum mounts and adapters.
4. Dynamo
   Similar to flywheels, dynamos are also used to convert mechanical energy into electrical energy
5. Reverse Motor
   Providing electrictiy to one side of the motor drives the shaft. However, rotating the shaft instead generates electricity on the other side. Essentially, by reversing the function of the motor, we are also able to convert mechanical energy into electrictiy instead. This accomplishes the desired function of both our dynamo and flywheel, all while being something that is readily accessible. The most important factor would be the rated specifications provided by the manufacturer.

 

Sketches for exploring methods to store energy then convert to electrical energy

---

Week 4&5 (2 to 13 June 2025) – Creating a basic circuitry and testing out the flow rate

We patched up a basic circuit to test the necessary electricity to be provided to the peristaltic pump, as well as to test the flow rate when the motor driver module is given the maximum input voltage (12V). More information was researched on the types of mechanisms to rotate the peristaltic pump / control the flow rate + provide the necessary mechanical input power to the electrical components. However, to reduce the flow rate to match medical applications, we also had to experiment 3D printed parts to connect to the pump and squeeze, but the exact mechanism used to pump out the liquid was not achieved as some of the pins of the 3D printed parts are fragile.

 

Testing out basic circuitry + flow rates from the pump

3D printed parts and their issues (the part on bottom left can be seen with two broken pieces)

[Video] Test with delay in Arduino code

[Video] 3D printed part issues

[Video] testing out the pumping, flow rate

 

Inside the MNT lab, there is handcrank electricty generator. The handcrank connects to a gear box, which is then connected to a motor. Taking inspiration from this machine, as well as a previous project done by one of the seniors, we are also aiming to replicate such a system.

However, the issue with crankshafts is the how long we must crank for to obtain our desired energy output. Basing our calculations from the motor inside the handcrank generator, it is rated for a maximum output of 50w. This results in around 1.5min of cranktime to generate 3600w of power. with the low power DC we were testing it, it would allow for 1hr of pump time. However, factoring in the efficiency of the motor as well as whether we are even able to obtain the speeds required, it is unlikely we will be able to produce this rated 50w. Aadditionally, the user might also not be able to consistently keep  cranking for the whole period.

Therefore, instead of driving the motor with a crankshaft, we plan to drive it through a pedaling machine instead. This way, the user is able to provide much more power, while being able to do so for longer and more consistently.

---

Week 6 (16 to 20 June 2025) – More accuracy on the flow rates + Developing the user interface via LCD and buttons

By modifying the configurations of the Arduino code (and reducing the time that the Arduino “sleeps” before running the motor at different analogWrite() rates), we were able to reduce the flow rate of our motor as well as make the results more consistent. We were able to achieve a consistent flow rate with errors from 0.02% to 4.09% from the average flow rate for a specific configuration.

 

Different configurations and their results, error percentages

 

The user interface was also developed for more convenient selection of the flow rate.

 

User interface demonstration and how the display system will look like in prototype

[Video] User interface demo

Following the formal presentation, we have moved towards methods for energy generation. Inspired by the handcrank generator, we further looked into it and developed the idea.

Initially using a handcrank, we estimated that we would be able to achieve 1 hour of pump runtime with just under 2 minutes of cranktime. However, this would require constant and consistent cranking for 2 minutes, which could get quite tiring and unreliable.
Instead, we looked into achieveing the mechanical effort from the pedalling with legs instead of cranking with hands. The legs have much bigger muscles and are able to produce much more force compared to the hands, while also being much more feasilble for pedalling the required time. This also gives us the freedom now to fully design how we would translate the mechanical effort from the legs to electricity, instead of just adapting the pre-existing handcrank.

 

The most obvious method would be to get a bicycle and then directly add on gears and timing pulleys to drive the motor shaft. However working with bicycles gets very tricky.
– They use chains and sprockets, as compared to traditional gears. This would thus make adapting from the sprockets to gears necessary, which is very difficult.
– Forces output by human legs can be quite high and we would need to ensure that all components added on would be able to withstand such high forces and torque.
– Ensure that whatever add-ons to the bike/axles do not interfere with leg movement during pedalling.

The alternative we settled for is using a simple pedal exercise machine:

The issue now is on how we will again translate the rotational movement during pedaling to rotate the motor shaft.
Originally, we wanted to fit a metal timing gear into this metal piece, where we can then run a timing pulley to translate the rotational movement to the motor shaft. However, the axle within this pedal exercise machine is angled and folded, making it impossible to fit the full metal timing gear into.
1 alternative method is to use an angle grinder to cut this metal piece into 2, where we can then fit in the timing gear, followed by welding it shut. However, angle grinding followed by welding would cost significant loss of material, as well as a decrease in the structural integrity of the material. Furthermore, to cut stainless steel(what this metal piece was made off) then weld it back would be very difficult.
The other alternative is to create a custom gear pulley. The idea here is to perfectly and continuously slice the timing pulley into 2 piece in CAD, where i can later 3D print in 2 parts. After this, i can now place them easily to fit into the axle. Lastly, there would be holes along the outer diameter to secure both pieces together. This seemed more feasible than the cutting and welding back method. The only issue is whether the PLA plastic material used in 3D printing would be able to handle just high forces, especially since the teeth of each pulley would not be very thick, thus making it difficult for the 3D printer to fill in with enough material.

The other aspect here is then the motor that we will use to generate electricity. It is thus very important here to purchase a motor that is rated to perform well at our desired conditions. With legs being able to output close to 1000N and cycling for up to 120rpm, we have to ensure that the motor will still be operating within rated specifications.
On top of this, we have to ensure that the motor is also back-drivable, meaing that rotating the shaft instead, should then also generate electricity.

 

From the research and calculations, we found that this motor is one of the only few that is rated to perform at our desired specifications, with an efficiency of close to 60%:

Presenting these findings and plans to Dr Ho, he did raise up a good point on the necessity to even create an energy generator from scratch. There are already pre-made energy generators, much like the ones we were inspired by, but using pedalling. This pedal generator from aliexpress costs around $200 after shipping, which would be close to the cost if we wanted to build our own generator as well.
Therefore, as we settled with this premade energy generator, it helps to free up more time for the design and features of the medical pump itself.

 

---

Week 7 (23 to 27 June 2025) – Development of physical prototype, More accurate measurements for the flow rate, Integration of two Arduino

Moving on, we decide to also explore the possibility of using stepper motors instead of DC motors. On paper and in practice, they seem to provide much more accuracy as well as consistency to the flowrates. However the downside is that they have a much higher power draw, close to 3X. Therefore, the idea of DC motors were NOT scraped, but instead other ways to increase their consistency was brainstormed. The method we settled on was to manually increase the torque provided to the pumps by trading off their speed. This would be alright anyways as the flowrates produced by the DC motor were already too high for typical medical use.

Initial casing prototype

 

 

 

 

 

 

 

Stepper motor progress:

Flow rate updates

Experimenting the flow rate using a more precise weighing scale that can weigh up to 0.01 g accuracy.

Integrated a system to communicate between two Arduinos via UART, to transmit the user input data (interpolated data from SD card) to the second Arduino, which controls the stepper motor. Accurate reading is achieved for high flow rates, however, low flow rates still tend to fluctuate due to the trapped air bubbles, which draw more water (as opposed to a controlled precise flow).

[Video] Integration of Two Arduinos for dispensing water

DC motor with gears progress:

Moving forward from the feedback from Dr Ho, we placed an order for an already assembled pedal power generator and put more effort in the design and function of the pump. As mentioned above, the possibility of working with stepper motor were explored. They still do have their own drawbacks and thus a seperate system that works with DC motors is also being further developed. An idea we previously thought up was that since the dc motor from the previous testings already produced too high a flowrate is run continously, regardless of whatever PWM we gave it(without stalling), we could use gears to reduce down their flowrates to something more reasonable.
Additionally the previous testings also showed that the lowest possible pwm without causing motor from stalling produced a flowrate up to 750ml/hr, which was 3x what we had hoped to achieve.
Therefore, with that in mind, we set out to make a design that would reduce the flowrates.

Week 8 (30 June – 4 July 2025) – Setting up proper gravity feeding bag, finalizing flow rate readings

Stepper motor

The setup now includes a proper gravity feeding bag to simulate the liquid feeding environment of a real medical application. The accuracy of the high flow rates has been achieved to be up to 99% (only around 0.2% error in most cases). The bubbling issue is still not addressed, however, the experiments can be repeated and the data can be updated into the SD Card reader module.

 

DC motor with gears:

Although using gears slowed down the speed of the flowrate, and the increased torque ensured that there was no more slipping in the persistalic mechanism, but there was still the issue of cosistency and accuracy. Therefore to integrate with the gear system, a PID controller system would also be added to ensure it’s accuracy.
PID controllers would require a feedback system, something that tells the code and arduino what is currently going on and the system’s performance. Ideally, one such sensor we could use would be a flowmeter. However the integration of flowmeters would be tricky as there are not alot of readily made flowmeters that could test such small tubing diameters, as well as the low speeds that are used. Additionally, it could cause a hygiene and health risk as passing different types of liquids through this flowmeter could cause contamination and unwanted reactions. Therefore, the sensor to be used was settled on a rotary encoder. This rotary encoder is able to record down the progress of it’s rotation in terms of ticks. The one we bought for this has 20ticks per revolution, so as the rotary encoder moves 1 full rotation, 20 ticks will be recorded. Pairing this with the gears in the DC motor system, we are able to track the rotations made by the motor as well as the peristaltic mechanism.

 

Week 9 (7 July- 11 July 2025) – Integration of DC motor and gears

With the drawings of all the components ready, as well as the code for the PID controller, it is now time to get them all together! Finnicking around with the dimensions and tolerances, the motor was able to connect to the rotary encoder as well as the other gear to drive the pump rollers. And it works… kinda. Giving the motor full power(Write255), the motor was able to drive all the gears and components, as well as fluids within the tubings. However this gave a very very fast flowrate, which was not desired, espeically since wanted to implement in medical settings. Even after using the gears to try and manually slow down the flowrates we could not get the desired flowrates. Trying to decrease the speed by restircting the power given(scaling down write 255) only worked till analogwrite to 200. Anything below that speed would stall the motor. We could bring this down to 180 if we did not connect in the rotary encoder as it does take quite some torque to rotate the encoder and actuate the ticks. Further trying to slow it down by decreasing the voltage provided was also possible but it worked only with analog write 220 or higher. Nonetheless, no combination of this manages to achieve our desired low flowrate targets.

In the end, because of how analogwrite works, decreasing it’s value directly decreases power given to the motor, meaning that its not that speed in trade off for torque, just that both the speed and torque is reduced together, proportionally.

Week 10 (14 July- 18 July 2025) – Troubleshooting and making tweaks to correct issues

Last minute scramble to get more components for the project. To deal with the issues mentioned in last week, we decided to :

1. Get another motor, which is rated for much higher torque and lower speeds, all while achieving comparable power draw
2. Swap out our type of encoder

We bought another motor which is rated for 30rpm, of up to 2.5kgcm torque. As for the power consumption, it is a 12V, rated up to 0.3A motor. This would give a power draw of 4W, which is much higher than what was achieved with the original motor. However, it is really unlikely that we will have to draw this much power from the motor due to our use case. In fact from the testing in our system, the motor draws only 0.04A, which is much lower than our previous motor even! and this is great for both the battery life and power generation aspects.

As for the encoder, the previous encoder was a simple traditional encoder, which discrete clicks between each of it’s tick and only offers 20ticks per full revolution, meaning that we are only able to takes 20 samples per rotation. After some research, an optical rotary encoder was something we found, and although more expensive than the traditional encoder($2 for traditional to $19 of the optical) it offered much greater specs!

After putting everything together, we are encountered with a new issue where there is no flowrate even though the gears and motor are moving. Even worse, if the outlet is placed lower than the inlet tube, the water is able to move down due to gravity but we are able to stop it from moving.

So we are having 2 issues right now. There is not enough suction to draw the fluids in when the tube is empty, and even when the tubing is full of water, the fluids still do not flow. Second, when the motor is stopped, there should also not be any flowrate of water. Going back to the initial design of the peristaltic pump, we noticed there is a protrusion on the inside of the cap to the peristaltic pump. It is possible that this cap is used to push and maintain the tubing in place as when the rollers are moving, there is a tendency for the rollers to move outwards. This could result in lesser occlusions and suction and also explains why fluids are going through even though the motor is not moving. Because the tubing have moved outwards and no longer as occluded, it is easier for fluids to go through.

Therefore, to resolve the issue, this same protrusion was printed into the gears that covers the peristaltic pump. Additionally, slightly thicker rollers were printed to try and squeeze the tubing even more, therefore creating more occlusion and more suction force.

2nd casing prototype

 

Week 11 (21 July – 25 July 2025) – Final iterations and integration of all components

Coming into the final week, this is our final design for implementing dear to reduce the flowrate while maintaining consistency and accuracy.

The 4 pump rollers did not work as well as intended. Due to the already small size in the pump enclosure, it was difficult to squeeze all 4 of the rollers into, while also having room for the tubing and still being able to rotate smoothly. Therefore we reverted back to the 3 rollers design. Additionally after the incoporation of the catch in the gears to ensure that the tubings remained in place and do not slip out during operation, the pump was now able to properly drive fluids through the tubings. However there was still a small issue where after a period in operation, the tubings pushes against the gear and everything starts to slip out. Once this occurs, proper water flow is no longer able to continue. Therefore the blocker that was pressed up even tighter on against the gears to ensure that it stays in place. However, now there is a small issue where the blocker and even the pump enclosure mount are starting to bend. So reinforcements and ribbings were added to further increase structure and prevent bending.

Even better, now that we ensure that the tubings are fully seated in the pump enclosure, the pump is able to draw fluids from the reservoir even though it is empty, which was previously very difficult. Additionally, once the tubing is full and the pump stopped, there is also little to no leakage, depending on how tight and seated the tubings are within the enclosure.
In the end, we did not proceed with the 4 rollers design as it was difficult to squeeze all 4 of those roller inside. Instead, we 3d printed just slightly thicker rollers but stuck with the 3 rollers configuration. Hopefully with the thicker rollers, it would push against the tubings more, creating more occulusion, thus preventing leakage when the pump is not moving, and effective persitaltic effects when the pump is moving.

(This was added at the end, but just placed here for better flow) Additionally, in the end, we supported the blokcer with another piece of plastic as we noted that the gears still has a tedency to slip out of it’s enclosure, and when it does slip out, it results in in effective occulusion of the tubings, thus causing leakage and ineffective peristaltic effect.

PID control:
With water being able to properly flowing out of the tubing as the rollers creates the peristalsis, we can use this data to calculate it’s flowrate.
– Clalibration:
By setting a fixed number of ticks that the optical encoder will record before stopping, we are able to duduce down the flowrate in both ml/h as well as ml/tick of encoder. This calibration step to obtain the mentioned data is critical as the later components of the PID controller heavily relies on the data produced here.

– Controller
By obtaining the values mentioned above, we can now continuously monitor the system via the Arduino and this information is then feedback to it too. From here. calculations and recording are being continuously, which will then go back to affect the flowrate.

With the initial set of calibration data, we can see that the pump is able to provide close to 10000 ticks every 30s. From the collection of fluids we are also able to obtain the flowrate in terms of ml/h, and also ml/tick. This is crucial as this data is then fed back into the PID controller and is used to calculate and correct the instantaneous flowrate of the system.

Sadly on 23/7, our motor driver was fried 🙁 So we had to use back the old L298N motor driver. This initially moved away from this motor driver as it was old and not very efficient, and this can be seen again from our tests as power consumption was close to 2x that when using the newer tb6612fng motor driver. Additionally, previous calibrations and calculations with the tb6612fng was needed to be redone. Furthermore, due to efficiency benefits, we were able to run the tb6612fng to as low as analogwrite 30, but now we could only make a minmum of 80 work without the motor stalling.

From the calibration done today, we could see that it now takes around 34s to hit the 10000ticks target. The calibration tests were run for 20 times, where the values are then averaged out and then used for the PID controller.

 

Regardless of the motor driver issues and gear slip issue, with the calibration done, we were now able to start on the PID controller component. With the inital deafult values of

P:5
I:1
D:1

We see quite abit of oscillations and the flowrate that was obtained very much lower than the set flowrate. However, it can be seen that as we plotted out a running average of the flowrates that it is slowly moving towards the set flowrate.
However according proper PID controller testing and settings, we should set both I and D to 0, only working with P to ensure a system that achieves our set flowrate (or very close to) at a desirable time. Only after that, than do we adjust the D, which should help to reduce the rapid oscillations issues and lastly I to get rid of the final small difference between the set flowrate and actual flowrate, albeit in a more controlled and slower effect than for P.

From testing, we found that a P value of 500 works the best at getting the system to achieve a steady state flowrate, very close to the set target flowrate, at a good timing. However, we are met with the issue of very wild and big oscillations. Turning up the P values from 0 to 1 helps slightly to reduce this oscillation. However, any more increase from there instead results in even greater oscilations. Finally, a low I value of 0.1 to help get rid of the remaining small steady state error was implemented.

In the end, there is still quite alot of oscillations in the PID readings so more testing would need to be tested.

As for the accuracy of the DC motor after implementing the PID controller, there was still quite some difference, with up to 15% of error from the recorded and target flowrates. Additionally, trying to tune the PID controller would results in wild oscillations recorded and the behaviours from the gears would be very jerky and erratic.

Even when testing the PID controller with a fixed constant input of just analog write 75, the input signal read from the optical rotary encoder still sometimes shows unpredicatable spikes in the flowrate read. These kinds of noise could be from the electrical system side, as well as mechanical factors like small vibrations in the gears or encoder that gets registered as extra steps.Regardless, to deal with these issues of noise and clean up the input signals into the PID, several filtering methods was used.

1. Low Pass filter (EMA)

A simple low pass EMA filter was used to smooth out the input signals. By combining new input signals with old input signals helps to smooth out noise brought in by the sensor.

2. Median filter

Much like the low pass filter, the median filter also took into account the previous values recorded by the sensor. However the difference with this filter is that it instead takes the most recent 4 values, follwed by finding the median value, helping to again deal with crazy spikes  in the signal.

3. Dyanmic Deadband Filter

Origianlly the deadband filter was just a simple filter that ignores error signals that are too small. Essentially, this is again to deal with noise signals, however this time when the system has reached steady state. During testing with the first deadband filter, it was just ignore errors that were lower than 0.2ml/min. When tested in the system, it would result in the pump reaching steady state and performing very well and smoothly, however always being 0.2ml/min away from the target setpoint.
Therefore to deal with this issue, i have modified the deadband filter to change their dead band once the systems reaches steady state. There the deadband would oscillate between 0.1 and -0.1, which when observed under testing resulted in the flowrate also oscillating between these 2 values.

With all these filters implemented in the system, the PID controller was perfomring much more smoothly.

Final PID constants
Finally going back to adjusting the PID constants, a combination of the above provided a great system behaviour, one well suited for medical applications. A Kp of 35 was the minimum before the system starting to oscillate wildly but not even being able to reach the setpoint target. To add on to Kp, a Kd of 3 and Ki of 10 was added. The Kd value helped to deal reduce the oscillations mentioned before and the Ki value helped to compensate back the ‘lost’ amount of fluids that were not dispensed as the system was moving towards steady state. Additionally, it constantly records down all error readings recorded and ensure that the average flowrate would be the target setpoint, and deals with any slight amount of deviation from it.

By the end, we managed to achieve really good PID controller performance, as it just moves around +- 0.1 of the target flowrate, all while providing smooth flow.

However, this does not directly result in accurate flowrate output. There is still alot of work that needs to be done with the calibration side to ensure truly accurate and reliable results. Sadly, this is not something we were able to complete by the end of the project.
However, the plan would be to get an multiple sets data of the pump performace (volume of water recorded) across a variety of pwm given. Based on the current PID configuration, it assumes a linear relation between the flowrate and the motor speed. However in practice, this might not be the case as lower power not only results in lower speed but lesser torque as well. Therefore by testing along a wide variety of PWM, we hope to create similar to what was done in the stepper motor part, where we can create a table/graph that now the PID controller can refer back to and interpolate a more accurate PWN for their desired flowrate.

Additionally, depending on the height differences between the pump and IV bag, or even the remaining fluids in the IV bag, all these may result in small effects on the flowrate. For height differences, maybe a simple method to check for height differnce could also be used as a factor for calculating the output pwm. Similarly, a timer for remaining fluids could also be used to slightly correct for the pressure difference in the IV Bag fluid levels from the start to end.
An alternative would be to look out for pre-exisiting algorithims and calculations that already help to consolidate all these factors and give us an input PWM that would work for each desired flowrate.

 

Updates on the stepper motor flow rates

By configuring the setup in such a way that the water reservoir (gravity feeding bag) stays level with the stepper motor and the measuring cup + weight, we have eliminated the water gushing and interfering with the constant flow rate. Moreover, we have achieved the most stable results for fast flow rates in this configuration. Both the original configuration and the interpolated values can be achieved up to 99%+ accuracy.

 

The following are the original configuration readings and original + interpolated readings for fast flow rates.

 

It is observed that the two graphs follow a similar exponential decay function, however, the (original + interpolated) flowrates graph has some jittering throughout the graph (which is realistic as real world experiments cannot follow a perfectly ideal graph).

As for the slow flow rates, the following graph is plotted from the acquired from the data:

More jittering is observed, and upon topping up the water, the reading of a fixed configuration would change, for example, if the configuration is set up as stepper.move(2); delay(30); –> the first reading would read 200 (following up readings would also read around 200), upon topping up the water, the reading would read 215 or 210 etc. Hence, although a general exponential decay function is observed, the setup cannot guarantee the same readings for all values, and instead result in a +5% or -5% reading inaccuracy. Hence, the dc motor is used for controlling the low flow rates, and this concludes the progress of the stepper motor for this project.

Cad drawing of internals

 

Overview of final product

 

User interface

1. Choice of 2 modes – high flow rate (650-5270ml/h) & low flow rate (52-649 ml/h)

• Turn potentiometer to select mode
• Press green button to confirm selection

2. Enter desired flow rate

• Starting from leftmost digit, turn potential meter to select digits between 1-9
• Press green button to confirm selection
• Repeat selection for remaining 3 digits

3. Stepper pump begins dispensing water at selected rate

Placement of pumps

• Both pumps are placed outside the box, isolated from the electronics.
• This prevents any potential water spillage from the pumps from affecting the electronics placed in the box

Side of box

• SD card: stores data collected from our experiment; where the data is used for interpolation of flow rates for stepper pump
• Plug: can be connected directly to power supply or rechargeable battery (charged using bicycle power generator)

Elevations

• Used to ensure stability of box by providing slight elevation since screw heads used causes base to be unstable