We live Next to Ringkøbing Fjord, a shallow watered large nearly closed fjord. So it’s obvious that we should have some kind of toy for those summer days where the Water is magically calm. Begging for something that moves fast.
Which Means: We would have to build a speed boat! A quick Google leads you inevitably to the Minimost site. I have never build a boat before so it seems like a resonable place to start. It can’t be a standard boat, that much is sure so it has to have some Kühlmeier signature. What about a part carbon fiber version of the racer!? Yep. That will do. So part of the load carrying stressed skin structure of the boat will be build using unidirectional high modulus carbon fiber as reinforcement. Mostly for additional stiffness purpose. Where do you get that stuff? Well if you work within the wind turbine blade design business and have your contacts… Otherwise it is not easy and surely not cheap.
I added some Pictures on the build process. below. In short I made use of 6 mm plywood for the deck and sides. 22 mm plywood for the transom, frame and keelson. The keel and stringers were 45×45 mm and 95×45 mm stock wood.
The assembly was made with all Wood screws and all connections were glued with Hempels Epoxy adhesive only the carbon fiber UD was fitted to the lower and upper deck with Araldite 2011. A super stong multipurpose two component epoxy system.
Overall a nice build process. And the result is pretty nice. We look forward to getting it on the water…. So More to come shortly.
First test run will be with our 6 HP engine. We know it’s not enough so we already borrowed a 15 HP to test it out… Let’s see 🙂
Saturday morning we found an old Lego RC car. Actually Duplo car to be precise. The relevant thing is that it had two internal DC motors and we had two IRF520 boards from Keys.
These boards are essentially driver boards for a MOSFET transistor. In short they allow the Raspberry Pi to switch the motors on and off. And also to control the motor speed py PWM (but unfortunately not direction). Freely shipped from China the IRF520 is less than two Euros pr. piece. Versatile and fun. So make sure to buy a few more than you actually need :o)
The idea was to be able to control the Lego RC car from Scratch using some sort of GPIO control. We quickly discovered ScratchGPIO5 which very quickly became or new favourite tool! It has lots of support for add-on boards for the Raspberry Pi and the possibilities seem endless. Imagine it works with the Adafruit 16-Channel 12-bit PWM/Servo Driver! So that we have to try out at some point.
ScratchGPIO only works with Scratch 1.4 but not 2.0 since the Scratch people for some reason have removed the “remote sensor” option from Scratch 2.0(???).
Next we quickly set up our Raspberry Pi as a Scratch Interface Device following the instructions on the ScratchGPIO5 site.
First step was to slaughter the RC car. Carefully since we wanted it all to work when we put it together again.
Then we soldered some longer red/black wires on to the DC motor terminals so we could put them where we wanted them later. Also wires from the battery pack + and – were soldered with wires in appropriate colours.
When this was done it was time for a test run before assembling the car again.
When we were happy with the result we could put it nicely together and this was more or less it. Done! :o)
Time for programming the basic features in Scratch to allow keyboard control over left/right/forward and speed.
Here is the final result. A nice little car which is easily controlled from Scratch. And there are still plenty of GPIO’s available on the Pi so we may just expand the world of the car some other Saturday.
Sunday hack: Now also with head lights which we can dim from 0 to 100%. Using the last MOSFET in the box, 2×12 V bulbs we had lying somewhere and a battery pack from a broken softgun.
We will NOT try and bring this throgh an airport security anywhere! :o)
Latest update: Now mounted with an ultrasonic sensor. This module is supported in ScratchGPIO5 and only takes up one GPIO pin. It is fairly precise and accurate. It gives a new dimension to the robot car since it can now “see” what is in front of it and react on it.
For the fun of it we are also streaming the data to plotly since we had an idea about monitoring and streaming the operational states of the robot car. But we are not exactly sure why. At least for no other reason than because it’s cool to do some IoT stuff and streaming of data to a graphing service on the internet. Could come handy at some other point.
Have a look see here. Perhaps it is on-line streaming right now 🙂
The Pyhton script for doing this involves both connecting to Plotly and also connecting to Scratch from Python to poll some sensor data and stream these to Plotly. So others may find this interesting since this is how you get Scratch to plot whatever in Plotly. It does not need to be streaming data. So I uploaded the script here.
“You know I think sniper rifles are really cool right?”
“You think we could build one down in you workshop?”
… So searching pictures on the internet and printing profiles in 1:1. We glued the prints on to plywood and used a jigsaw to cut the shapes.
A football pump is used as silencer and some used 30.06 shells from my old rifle are mounted in the clip… Well and then some paint and 16mm steel tube for tripod and barrel. Plus an old second-hand Bushnell sight… Here we go :o)
The array is 224 cans with an active surface of 2.1 m². The principle is simple. Drill holes in top and bottom of a bunch of cans. Glue the cans together to form long tubes. Then paint them black and use a fan to draw cold air in from one end and blow hot air out in the other end as the sun heats the air inside the can-tubes.
I mounted the cans so they are “floating”. I.e. not touching anything but a few supports. This is to avoid any heat to be lost from heat transfer to a colder object. Then placed all the cans in an isolated box with a reflective surface on the inside so any sun rays passing next to the cans are reflected back up on the can from below instead of heating up the box. The whole thing is covered with a sheet of 3mm UV-stable polycarbonate and carefully sealed with silicone so no water goes where it’s not suppose to.
Status May 2014 is that the solar heater has been assembled and the initial function tests has been performed. The prototype for the control is also assembled. 1 Raspberry Pi. 3 onewire temperature sensors. 1 Pecan relay board. 1 luminosity sensor (for fun) there is a complete parts list at the end of the post including links to products. Combined the prototype assembly of the above ended up looking like this 😉
Pretty? Nope. But it does work.
Check out how easy it is to set up and use the DS18B20 digital 1-wire temperature sensors here. Note that you can have a number of these sensors connected in parallel(!). They are just individually addressed by their unique serial number. Very nice 🙂
The Pecan relay does not require any setting up. It simply works with the RPI’s GPIO Pin # 25, 17, 27, 22, 23 and 24. And then a connection to ground (GND). The relays are opened and closed using any GPIO access library. Of which I will recommend WiringPi. Setting e.g. pin #22 to high (gpio -g write 22 1) will close the relay. And setting the same pin to low will open the relay again: gpio -g write 22 0. Easy. The Pecan relay board does require its own power supply since the relays draw a bit too much power to be run from the Pi’s 5V line. But you can set up the relay board such that the Pi is powered from the Pecan board. Effectively this means that you still only need one power source. Just make sure it’s one with sufficient power. 1A should do fine.
When you have these two things talking to your Pi you are pretty much ready to start coding.
I have build a web interface for the solar panel using the brilliant Internet of Things framework WebIOPi for Raspberry Pi. I love the simplicity of getting software and hardware to interact and the ease and flexibility of linking stuff to a web interface with some Java and HTML and whatever you like :o).
I found it to be a rather steep learning curve getting familiar with how WebIOPi works. But once you grasp the concept it is really easy and powerfull. So stick with the tutorials on thier project page and you will quickly learn enough to start having fun with it.
Unfortunately I have found the python bit of WebIOPi somewhat unstable. It will crash after a few hours of running regardless of what I have tried. The debug output gives some hint that it is the 1-wire sensors which from time to time output very low values and that is giving some problems. I couldn’t be bothered with trying to fix it so I gave it up for now (but looking very much forward to the next release!). Instead I am running a shell script once every 10 min which stops the WebIOPi daemon then runs a stable python script to check the state of the sensors and set the fan to On or Off. Lastly starts WebIOPi again. I.e. shell script looking like this: sudo /etc/init.d/webiopi stop
sudo python mypath/solar_panel.py
sudo /etc/init.d/webiopi start
Save this into a run.sh file using: sudo nano run.sh
Lastly set crontab by crontab -e to run every 10 min:
You can view the source of the interface script (index.html) by right clicking on the page and choosing “view source”. The script.py for the WebIOPi I just left performing nothing. So it want mess anything up. You can’t have any GPIO access libraries running at the same time as WebIOPi. That is why I close it down before running the python script as this uses the mentioned GPIO access library WiringPi.
The solar panel is to be mounted on the roof of my summer house and a fan is drawing in the hot air from the array and into the house. Schematically the whole thing is shown below. T-out is the temperature of the outlet air from the solar panel. T-in is the inlet temperature (i.e. the outside ambient temperature). T-room is the inside room temperature.
Control thingy is quite simple:
Turn the fan On when T-out is 10°C larger than T-room.
Turn the fan Off when T-out is less than 5°C larger than T-room.
Turn the fan Off when T-room is larger than 22°C
Some photos of the building/assembly/installation process:
Another smaller Raspberry Pi project. This is in addition to the Growatt inverter read-out project where I keep track of energy production from my PV array. The next obvious thing to ask is how the energy consumption compares to the production. I.e. I need some way of measuring the energy consumed in my house hold. Looking at my power meter it is a sealed box and I am not interested/legally entitled/brave enough/smart enough to do any measuremets on the high voltage side of the system. But I was inspired by a colleague to utilize the small blinking LED on the power meter to keep track of energy consumption. The idea is quite simple since the LED blinks 10.000 times pr. consumed kWh… Yes you get the idea. The blink speed is a measure of power and the total number of blinks is a measure of energy. Making a few Google searches quickly revealed that the idea is not novel. There are several applications like this out there. Even commercial systems are available which are not that expensive and also offers some cool features. But hey! There is no need to go to the extremes and buy something reliable, ready made, cost effective and installation friendly when you can have some hours of fun making it your self.
I found this easy to understand and built circuit found at Adafruit. This circuit is actually not that well suited for the application since it will only give you an instantaneous reading of the light intensity (or an indication hereof anyways), which is a little tricky to translate to blink or no blink situation. This is a first version of the blink counter and if it does not work reliably I will upgrade it to a transistor type circuit as e.g.: http://electronics.stackexchange.com/questions/38258/plugging-a-ldr-into-gpio-pins-of-a-raspberry-pi
But let’s see how it goes. I have installed a 0.1 µF capacitor to be able to get some fast readings. Back-of-an-envelope calculations says that the blink rate at extreme consumption will be 20 kW*10.000 blink/kWh = 56 blinks pr. second which the circuit should be capable of following. That is one blink pr. 18 millisecond. The circuit at it’s present form looks to be fast enough at least up to 10 kW which was what I was able to test turning on all the rings on the stove and the teaboiler too :o) Much more than consumption than that is probably not going to occur I hope. The python script which I wrote for this is under ways. I’ll just debug a bit on it before I publish it here so it will be fairly well tested and stable when it hits the site .
Pyhton code for running the blink counter and upload to pvoutput-org is available here. The script will count blinks for 5 min. Then recalculate the blinks counted to an average power over the time period and he total energy. Subsequently both are uploaded to www.pvoutput.org. (Production from my PV array and the household power consumption can bee see here)
In its current state the script is run 5 min past midnight each day. The script then runs over a while-loop the entire day and writes data to a text file each min and uploads data to pvoutput.org each 5 min. Then when the date changes the while loop in the script ends and a new text file is created for the next day… Hmm. I just need the text files for a detailed look into if the counter counts correctly under all consumption situations. It seems to be running ok, but it’s a little hard to get a solid validation of since the power meter only reports consumption in kWh, which is a coarse resolution.
To set up the cron job use: sudo crontab -e
and edit the file to this
… does seem to be a fair question. In my case: The brew thermostat of my Rancilio Silvia died. Changing a thermostat is perhaps just as boring as fixing a flat bicycle tire. Adding a PID controller to an espresso machine however is good fun. Which must serve as a good explanation.
Good temperature control is claimed to give both higher quality and more consistent quality of your coffee shots.
The PID controller keeps a much tighter control of the temperature variations compared to the on/off thermostat control – as expected!
But I have to say that the Rancilio delivered superb quality coffee before the PID controller was installed – and it still does after the installation of the PID controller. So at least I didn’t break anything which to a certain degree is also a measure of success.
Please be careful if you disassemble any 220 volt device.
220 volts can and will kill you if you get in contact with live wires!
Unplug the device before you even remove the first screw!
Let’s have a look at the parts list
PID cont.SSRTemp. sensorMiscellaneous
Basically any off-the-shelf PID controller should do just fine. Important thing is that it has solid state relay control (SSR) output and not current output since it will be driving a solid state relay (obviously). Looking 10 years back PID controllers were horribly expensive. Nowadays there are some pretty cost effective reliable models for sale on eBay. Actually at the same cost as a genuine Rancilio brew relay.
I chose a DIN 1/16 size since it then fits nicely into my espresso machine or alternatively into a standard project enclosure so my wife and children are out of harms way when operating the machine. I.e. the 220V terminals are packed away and out of reach. The model I choose was a SESTOS D1S, but you may get even cheaper once.
There is much to say about PID control. Which I will not. There are plenty of resources elsewhere on the internet. I my self am an engineer and have sort of a basic understanding of what to tune in the controls to get a certain response (without being an expert in any way!). Luckily the PID controller will normally have an Auto Tune program which does a fair job in setting the control parameters. Try it out and if some fine tuning is still needed, in the case of unacceptable temperature overshoot or too long heat-up time, then consult here or drop a post or read further down and see if you get anything useful out of my PID “theory” section 🙂
You will want at least a 10 Amp Solid State Relay (SSR) which can take the net voltage 110-220V. They are cheap and reliable components. SSR’s does consume a bit more power (i.e. generates more heat) compared to electromechanical relay devices. It is not critical since it load it has to carry in your machine is only around 4 Amp for 220V installations. As far as I can see there is a specified voltage drop of 1.6V which must add up to 5.6W heat dissipated. It’s not much. I tried having it running for 2 hours lying on the table when I fitted the PID. it went no warmer than 30 °C… But make sure to install it in a fairly well ventilated space and not too close to other objects. Like wires and plastic shields etc. The SSR is best mounted on a metal surface.
One disadvantage of the SSR over your current mechanical relay is perhaps worth mentioning. SSR’s have a tendency to fail “shorted” on their outputs, while electromechanical relay contacts tend to fail “open”. This means that in the unlikely case of the relay failing then the boiler in your espresso machine will continue boiling even after the set temperature is reached. Have this in mind but don’t worry about it. SSR’s are known to as very reliable components.
As you see there are 4 terminals. 1 and 2 should be connected such that they power the heating element. I.e. connect them to the two wires attached to you existing brew thermostat. It does not matter which you put were as long as the two wires goes to terminal 1 and 2. Terminals 3 and 4 are the control input side. So they are for the PID to operate. Note that they have a + and – and this should correspond with the current output on the PID. for the SESTOS the terminals are SSR3 goes to PID8 and SSR4 goes to PID6.
On the advantage side you will have a completely silent relay when the SSR is in operation since there are no moving parts (no more “click-click” sound).
This is a (nearly irrelevant) discussion on it’s own. Several types of thermocouples exist but you just need one which is of the correct input type for your PID (see PID manual) and which covers the temperature range it is operating in. I chose a k-type sensor which was easy to mount and was available with a nicely insulated steel reinforced wire. The sensor type is a general purpose one which covers many applications more aggressive than an espresso machine mount so it will do just fine. As you see it’s response is also squat in the middle of the field when comparing the different thermocouple types available. But make your own pick. You coffee will taste the same I’m sure.
Note that you can cut off the end of the thermocouple and basically shorten it to any desired length. Just expose to two wires and twist hard them to ensure a good connection between them.
An important thing is the safety when you are dealing with 220V. So you need to make sure that all live wire terminals are well protected and out of reach. So you will need a casing for your PID control box. In my case I chose a DIN 1/16 size PID and measured out that it would fit inside the espresso machine. You may not want to cut a hole in your favourite household appliance! So alternatively you can mount it on the outside of the machine, but then put it in a project enclosure. These are readily available on eBay. The cut-out size for DIN 1/16 is 45X45 mm. If you find a box with an end plate a bit larger than this it is easy to unscrew the end plate. Make the cut-out and re-mount it with the PID installed.
Search the Electronic Components section on eBay for “project enclosures” and make your pick.
How is it all connected?
Some photos and drawings which may be of help if you want to try this out yourself: click to enlarge
The PID controller most likely have an auto tune program/feature. Let your espresso machine heat up for 30 min and then deploy the auto tuning. This lets the PID analyse the response of the system and set the gain or time parameters.
Try it out and see if you are happy with the result. In my own experience you will benefit from adjusting the parameters manually afterward. The main reason is that the auto tune wile most likely find the optimal set of parameters to include a good portion of integral action. Where this is a good thing to keep an almost undisturbed system stable it is not necessarily good for the system response you want of your espresso machine. When you press the brew button, cold water will flow to the boiler and the temperature will drop rapidly for a short time as you brew. Having a lot of integral action available in the control strategy will interpret this as a temperature which is offset even though heat is supplied. I.e. the integrated error will increase quite a lot during the seconds you brew. To make up for this, heat is supplied to the system until the error is again low resulting in a temperature overshoot of several degrees after each brew. This was NOT what you wanted. To avoid this set the integral gain/time low and compensate with differential instead. This worked for me. The temperature is at present time not quite as stable as it was using the auto tune parameters. But I manage with the +/- 0.7 °C temperature variations I’m seeing. Speed in getting to the set value and stable post-brew response is more important to me than +/- 0.1°C accuracy of the steady state temperature.
Enough silly talk about control strategy. You basically just wanted a cup of coffee right? 😉
So without further ado: