On our company's Christmas celebration (December 2013) all employees got a small present: A Raspberry Pi. This was the initial event for me to investigate what (internet of) things can be done driven by this tiny computer.

This blog is to document my findings and to share what others shared with me.

Freitag, 25. August 2017

sauna temperature measure device

Two years ago I built a sauna. Since our house has no basement the sauna is not within the house. It is in a detached house:

Especially in winter we don't want to waste to much energy and use the sauna as soon as the temperature is OK. So in the last two years we needed to guess after which period it is OK or go outside to check the temperature.

Now I installed an ESP8266 module to measure the temperature so I can check from inside the main building.

This is quite simple and takes just a few steps:
  1. Buy a DS18B20 temperature sensor
  2. Buy a nodemcu ESP8266 module
  3. Connect them as shown
  4. Install the software (see GitHub)
  5. Install the device in your sauna
 That's it 😊

How to connect the sensor
The sensor placed in the sauna
The ESP8266 module in the sauna
The result

Samstag, 19. August 2017

Irrigation management

We built our house only a couple of years ago. This year we wanted to build a terrace in order to get more out of our garden. Caused by the position of our well which we use for irrigation and the size of the new terrace, the well would be entirely hidden by the new terrace. It became necessary to install an irrigation system because once the terrace will be finished I won't be able to bring tubes into the well. Unfortunately irrigation systems are expensive so I decided to build it on my own.

Most of the irrigation systems on the market use solenoid valves at 12V or 24V. Some of them use rotating valves. Both is necessary because they need to be able to switch tubes of big diameters (e.g. PE pipes with 3/4" or 1" inner diameter or even more) and thus need power. In a normal sized garden (mine is about 800m² of lawn area needing to be watered) the region watered by each irrigator is not that big. A smaller tube diameter of 1/2" should be sufficient. If your pump provides a lot of water you can even choose to turn on two or three sprinkler at the same time, each connected by a 1/2" tube. You just have to use a bigger diameter for the tubes connecting the pump and the solenoid valves so each line is supported by enough water.

Nevertheless I want to run my irrigation sytem on top of the RaspberryPi which is powered by a 5V USB supply. There are no valves using 5V, but there are valves using 230V AC. Of course there is 230V AC available: the same plug socket which my RaspberryPi is connected to. But be aware: 230V AC is powerful but also dangerous and using it requires a lot of responsibility and carefulness - do not forget to unplug the 230V line after each test! Lucky for me the friendly chinese store got some cheap solenoid valves using 230V.

solenoid valves connected to the main water support line
(ignore the metal stripes on the wall - they are not part of the irrgation system)

So what's next? I used a relay panel to switch the 230V lines for the solenoid valves. I connected it to a level converter because the panel needs 5V inputs but the RaspberryPi only got 3.3V. It turned out that a converter is not necessary because the relay opens the N/C (normally closed) circuit once the input pin is pulled to GND. So the relay panel can be connected to the RaspberryPi directly. The photo shows the part connected including the level converter.
the RaspberryPi connected to the relay panel which is connected to the solenoid valves

The box is only for development. It is necessary to use a plastic box locked by screws to be sure the 230V lines are entirely hidden and children won't reach them! They are a danger to life!

At last a software is required to control the valves/relays. For a first draft I wrote a simple Java program which uses a property file to read the configuration from (see GitHub: https://github.com/RasPelikan/IrrigationManagement). It has a web UI for basic interaction like stopping/starting a certain sprinkler, pause an active irrigation cycle or shutting down the RaspberryPi. The software is started at boot time using the cron daemon.

So that's it. See it in action:
switching two sprinklers using the web UI

Right now the software supports GPIO based irrigators (switched by relays as mentioned above) and URL based irrigators. I bought some ESP8266 modules at the friendly chinese store mentioned before and wrote a simple Lua script (is part of the GitHub repository) which switches relays on calling an URL. I will use them to extend my irrigation system into the peripheral regions of my garden. This works at the bench and I will do another blog post once I can show it in action.

I also found a "ready to use" open source software on GitHub called sprinklers_pi. It seems to be nice and it should work straight forward using my relay switched valves. So I will give it a try. There ist also an open issue for ESP8266 based irrigators, but it does not work yet.

Mittwoch, 19. April 2017

ATX power supply

I began to think about the things necessary to build a table tennis robot. Next to the construction itself a lot of motors are needed!
I found a motor including a mounted wheel for accelerating the ball - it consumes 500mA at 3V. A second motor is needed for applying the spin. I need a lot of servos for different tasks, some are weak (consuming 150mA at 5V) others strong (consuming 1A at 5V). The RaspberryPi itself will need approximately 1A at 5V. The last part is a stepper which will drive the push mechanism to move the balls to the accelerating wheel.  That stepper will consume about 1A at 12V. So I will need a lot of current at 3V (1A), at 5V (~5A) and at 12V (1A).
But wait a minute: aren't those voltages provided by a regular ATX power supply? Yes they are. Except 3V but 3.3V will work as well.

There are some projects out there providing an ATX power supply for driving a RaspberryPi. But wouldn't it be boring simply ordering another part? It is much more interesting to build a circuit on my own. And this is what I did:

On GitHub you can find all information how to build it on your own:

Sonntag, 26. Februar 2017

Table tennis robot

Unfortunately it is a long time ago that I wrote a blog post. I was on the way to build a mowing robot.

On the way I had to invent a lot of things. Some of them are:

  • For Pi4J:
    • Pull request - Added MCP44xx, MCP45xx and MCP46xx families to pi4j-i2c-devices
    • Pull request - New Concurrency in I2CDeviceImpl and I2CBusImpl
  • AVR-projects:
    • Eclipse-Plugin - Use usbasp programmer to show up UART in Eclipse
    • Gadget - A silver screen remote controller
But since I could not tell my wife when the mowing robot will mow the gras in our garden, she did not want to wait any more and I had to buy a ready-to-use product. And yes, it mows the garden.

So what now?

In the last fall my sun started playing table tennis. Due the fact that this is some sort of "farther and son"-thing I also learn table tennis. And after the first lessons I recognized that it would be fantastic the use a table tennis robot for the training. A robot would be able to place every ball to the same spot, with the same speed and the same spin. So you can focus on refining your technique. As always you can buy a cheap model which won't make you happy on the long run or you take a lot of money and buy a good model. Or, you DIY :-) ... which not necessarily means that you will be happy on the long run :-)=)

In the very beginning a saw a lot of Youtube videos showing DIY table tennis robots. But I also looked videos of professional robots to get inspired. And after a couple of days I knew that I want to build a robot which one day might be better than professionals. But step by step: 
  1. The first "version" should be similar to those cheap models: They sit in the middle of the table and shoot the balls to the left, to the middle or to the right. The cheap robots only know top-spin oder under-spin. My robot should be able to create every spin (top, under, left, right, combinations). Additionally it should also be able to shoot faster or slower in combination with up- and down-directions. And, of course, a ball recycler: A net which collects all the balls I return during practicing and brings them back to the robot to shoot them again.
  2. Once this works I want to build a rail on which the robots moves. This should enable an advanced training mode and generates shoots like a human player would do. Additionally the ball-cannon should be able to move up and down. Especially for this version I can reuse a lot of things I already bought for building the mowing robot.
  3. And in the end I want to add a RaspberryPi camera module to track the ball and move the robot not only in predefined ways. It should move along the returning ball to shoot the next ball from the place the returned ball hits the collector net. This should give a feeling as playing with a person.
In the last three months I tried some of this features to see whether I could make it. And yes, it seems to be makable. So I will report about the progress, the problems and the solutions in the upcoming posts.

Samstag, 10. Januar 2015

LPS - Sending radio signals

A lot of things have to be considered if you want to send and receive a signal. I want to list those and my conclusion about them.

1. Radio-traffic

I intend to send a signal to a reference-location and the reference-location should return the signal. Doing so brings up two problems:
  1. The frequencies which can be used for general-purpose transmissions are limited. For example within the EU 433Mhz or 868Mhz may be used. So every garage-door-opener or weather station uses one of this frequencies which means you will receive a lot of noise made by other people's gadgets.
    To filter signals sent by the mowing robot to a reference-location I have to encode the data in a certain way which can only be decoded by the reference-location. To do so dedicated ICs can be used. I prefer HT12E as encoder and HT12D as decoder. But there are also other products available like PT2272 (Encoder) and PT2262 (Decoder). Those ICs encode a couple of bits into a stream signed by an "address". The decoder-ICs are listening for a certain "address" and spit out the bits set to the encoder once the address matches. In short: You don't have to be concerned about other people's signal-noise by using those ICs.
  2. Another issue is about bidirectional communication. Every communicator needs a sending- and a receiving-modul. So if the the mowing robot sends out a the signal its own receiving-modul will pick up the signal, too. In the same way the reference-location's receiving-modul will pick up the response.
    Sending any signals occupies the receiver. This means that the mowing robot cannot receive the response during transmission. At a first look this does not seem to be a problem, but for longer distances the duration of the sending has to be increased to guarantee a successful transmission. In this situation it might be that the success is already there in the very first milliseconds of sending. If the reference-location starts responding immediately the mowing robot's receiver will no see the signal because its own sender is transmitting a signal much stronger.
    This situation can be avoided in two ways: The easier one is to use another frequency for sending the response. Unfortunally I could not find an easy-to-use sending-modul available in both frequencies. So I have to use the second way which is by responding to the robot's signal after a certain amount of time, when the reference-location can be sure that the robot's transmission is complete. The downside of this way is that a lot of time is wasted. At the moment I cannot tell for sure but I guess using two frequencies is about 2-10 times faster. At a distance of 25 meters this means the robot will be able to contact only 3-4 reference-locations instead of 6-8 per second.
2. Sender-/Receiver modules

I was looking for cheap modules and found this:
  • Sender = FS1000A
  • Receiver = XY-MK-5V
They are pretty cheap and use very little current in standby mode (available at DX or Semaf). The amount of energy needed to run a reference-location is a critical issue. I will write about this later. For the moment: less is better.
Above, I mentioned that I could not find those modules at 868Mhz. There were other modules which do 868Mhz but they has to be connected by I2C or SPI. A pair of the modules introduced here can conceptionally be used in the same way as a cable. This is pretty easy and can be used in any electronic circuit without the need for a microcontroller.

The most websites reporting about the FS1000A-module tell that the range of transmission is from 2 to 200m. The actual value depends on several attributes:
  1. The module can be run at different voltages (3V to 12V). A higher voltage means bigger range.
  2. For the receiver-module a 5V supply is required so it would be easiest to apply 5V to the sender-module, too. Due to the noise at the frequency of 433Mhz I cannot tell how far the signal reaches, but something above 50m.
  3. The modules itself may send only a couple of centimeters. They have to be extended by antennas (both sender and receiver) to gain more than 1m. I soldered a 1/4-antenna (simple cable in a 17.3cm length) at the proper pins.
  4. At the outer ranges the signal is weak. So even if the range is 100m I won't be able to read any data or identify those data as mine at 100m.
  5. I was able to build a stable communication at a distance of 30m using a 5V-supply. For that I have chosen to stretch the signal as much as possible (lowest oscillation frequency - see datasheet of HT12E and HT12D). Additionally I set the enabled-pin of HT12E to active for 90ms. In this time the stream generated is repeated again and again. Usually one or two of those sequences could be read by the receiver at a distance of 30m. If the noise was low it worked up to 50m.
  6. Noise: I've mentioned it already above. The noise influences the quality of transmission and therefore the distance of possible communication. This has to be kept in mind for processing the ranges for position triangulation: The circuit will measure different values for the same distance in dependence to the current environment conditions.
3. Transmission attributes

I already mentioned that it is necessary to increase the time of sending for longer distances. The greater the distance between receiver and sender the more other radio-traffic of the same signal strength (of other people's gadgets) will disturb the transmission.

In addition to this effect the speed of transmitting has to be reduced for longer distances. This does not mean to modify the frequency. The HT12E-IC encodes the information I want to transmit into a stream of 0 and 1 digits. If I have longer distances the whole transmission has to be stretched not repeated more often. So for short distances a 1-digit might be successfully read if it is 0.1ms but for longer distances the noise scrambles the 1-digit so it has to be 1ms to be detected as a 1.

In the first try I will use constant duration and constant speed of transmission. Each value is selected so that it works at the longest distance I want to reach. To optimize the number of reference-stations to track per second I will try to decrease the duration and increase the speed of transmission in dependence of the distance. I intend to do this by transmitting the distance to the reference-station because the strategy I want to use for measuring the distance does not require transmitting a specific value - it only requires transmitting anything. So why not sending a value which can be used for optimization?

What's next? Let's take a breadboard and build a reference-location. Oh, wait. All my breadboards are in use. It seems I have to get them free. Stay tuned to what this means ;-)

Montag, 5. Januar 2015

LPS - The idea

For the mowing robot it is vital to know at every point in time at which location within a certain area (the garden) it is. Most robots that are available in the stores need cables put into the ground to define this area. Thoses cables are detected by the robot so that it knows when it reaches the border and has to turn around. The robot never knows its exact location and drives around at random. To find the base-station a special tracking-cable has to be placed which is passed by the robot from time to time. My garden is pretty big and it would be difficult (but not impossible) to place those cables. Additionally robots waste a lot of time and energy driving at random since they pass a lot of locations several times.

I want my robot to drive a certain path so that it passes every specific location only one time. For that reason I need some sort of ranging. The borders of the area should be known by the robot. If there is some sort of ranging the borders can be honored by it. How does the robot know about the borders? There will be a special administration-mode in which I will steer the robot by remote-control along the borders and it will record those positions.

So the requirements for location-tracking/ranging are:
  1. The resolution has to be close to 10cm.
  2.  Power consumption has to be low.
  3. Most of measuring-work should be done by a circuit to relieve Rasperry Pi's CPU.
The first idea I had is to use GPS. But GPS does not meet my requirements well:
  1. Standalone-GPS resolution yields about 2.5-1m (depending on the number and kind of satelite-signals receiving). I was wondering about this since geometers use GPS to place landmarks up to a resolution of 1cm. Searching the web gave me the answer: They use differential GPS. D-GPS uses a second GPS-receiver at a reference-location. The raw-signals of both locations can be used to get more precision relative to each other. Geometers use public reference-stations which provide their raw-signal through a special internet-protocol. But those services are not free and building my own reference station is too complicated.
  2. GPS-receivers consume a lot of energy (at least 100mA at 3.3V - this is not very much, but less would be nice).
So if global positioning is not suitable maybe some kind of local positioning will be? Local positioning works by triangulating distances to at least three reference-locations. But how to get those distances and what kind of reference-locations?

One possiblity is to use sonic. An example for a ready-to-use module is HC-SR04. But there are limits prohibiting sonic for local positioning:
  • The signal has to be directional, but usually the direction of those reference-locations are unknown.
  • The maximum range is 3m - the distances in my garden is bigger than 3m ;-)
  • Objects between the reference-locations (f.e. children's toys) disturb the signal.
So I will use HC-SR04 for collision prevention but not for local positioning.

So what's left? Radio! But radio-signal cannot be used in the same way as sonic is used to measure distances. HC-SR04 is measuring the time-gap between sending and receiving the signal. This works because sonic is a slow signal. Radio works at the speed of light so a distance of 10cm is passed in the time of the 2,997,924,580th part of a second. This is too short to be measured.

So this is the idea:

I build reference-locations which receive radio signals sent by the mowing robot and return those signals immediatally. The robot will listen for the response. The mowing robot's signal can only be returned, if it is strong enough to reach the reference-location. So I increase the signal strength in a loop by a very small amount starting at zero. Once I get an answer I know the signal strength which is in any correlation to the real distance. If I do this for at least three reference-locations and I know about the correlation between the signal strength and the distance I am able to calculate the local position. So far so good.

To proof this, three things have to be done:
  1. Build the robot's sending-unit and a reference-location-unit.
  2. Test whether increasing signal-strength for measuring the distance is reliable/reproduceable.
  3. Learn about the correlation between signal-strength and distance.
The next post will report about the steps I take to get this proof of concept.

Dienstag, 13. Mai 2014

Building PCBs - Part 2: Two sided PCBs

In my last post I used the toner transfer method to build a PCB. Sometimes the arrangement of nets of a layout get pretty complicated or impossible to figure out. Even auto-routing fails or results in arrangements hard to work with.
In this case it might be better to use a two sided layout: Whenever a net cannot reach its target you can use vias to switch to the other side and go on easily. For the H-bridge IC I use to run motors (see Control motors - Part 4: H-Bridge) I need a two sided PCB so let's see how this can be done using the toner transfer method.

Two sided PCB
First of all you need PDF-files of the mirrored layout of the top and bottom layer. They have to be printed to toner transfer paper. Afterwards I punched the 3mm holes at the edges of the layout which are needed to screw the board into a box. Now I put one layout on the copper and used a permanent marker to amplify the holes made before. After this you can remove the layout and you will see the positions for drilling those holes. The next step is to drill the holes.

Now you have two layouts printed to toner transfer paper and the board - all parts with holes at the same position. After cleaning the board the next step is to iron the layouts onto the board. Now I arrange the first paper using the holes: they have to match exactly. Next I put the iron on the stack for some seconds to make the paper stick on the copper. After this the board can be flipped to repeat the procedure for the second side using the remaining print. If both papers stick well you can flip the board several times to ensure each side is ironed as explained in my last post. The rest of the story is the same as for single sided PCBs: Peel off the media, etch the board and remove the residing toner.

The upper side of the board after toner transfer...
...and the lower side.
(the dark areas are minor defects I fixed using permanent marker)
After etching the board you can drill the holes needed for common elements or vias. Do not drill through the board. Sometimes the position of the layout is not as exact as it should be and drilling through could break nets of the second side. I drill from both sides to the middle of the board - similar to  digging a tunnel. If the hole does not match exactly it does not matter. The elements can be soldered even if the hole is displaced a little bit.

After etching and drilling you can see how exact your work was. I'm satisfied :-)
First note: If you prefer transparent film you can orientate the layout as shown in this post: http://www.instructables.com/id/Two-sided-PCB-using-toner-method/.

Second note: You might asked yourself which kind of vias I use. None! I build vias by soldering strand on both sides of the board. Before doing this I put the board on two stencils. This builds a distance which helps to ensure that both sides can be soldered well. After soldering the excrescent strand can be cut off.