Software apps and online services
Hand tools and fabrication machines
Thinking about home enlightment system, I often come to realize how many potential light spots I'd like in a single room:
- diffuse soft light, maybe reflected onto the roof or a wall, to watch a movie
- couchside lamp for reading
- direct focused light on a workstation desktop
and so on!
Across the day and when needed I actually use different lamps for different atmospheres. So I had the idea to make a single device capable of moving and rotating in a range of positions, capable of focus narrow and wide light circle: and dimmerable!
Then, it should become even smarter being controlled by voice commands with Alexa. There can be a lot of possible practical applications.
..Imagine a dress shop and a customer that can appreciate all the shades, colors and reflexes on his new suit or on her new shining night dress, by a moving lamp that perform a revolution around customer's position; at the clerk's voice command.
Even trivial tasks, like having a light not only when you open the fridge at night but also when open any sideboard's door.
As a spotlight, light up a person making a terrible joke - like he was on a stage; would be at least comical.
Or a discrete lamp to search for keys or slippers when coming home late, trying not to wake up everyone by turning on full lights.
Or rotating fast 180° like a disco globe or an alarm.
Then explore potentially very complex tasks ...Imagine asking it to point the current position of the Moon (connected to the web for time and date, should be possible); or point the position of a fixed object ("where we keep sugar?", "where was that book?"); even a moving object ("where is my cellphone?!") - but it should be able to find it before me in the first place.
Back to earth and feet on the ground,
first goal of Sputnik project is to build a functioning prototype.
Next, I imagine a potentially professional smart-home device that everyone would have in their living room, office, shop or laboratory.
Here a video with the actual state of the project.
Moving in xy space can be performed via a plotter structure - but for an entire room seems to be a too big structure.
I thought about cables fixed on top of the walls: a roller can wind the cable as a string. For stability cables should be 3; these have to be controlled by 3 different motors. For weight reduction I prefer to place them in wall devices instead of inside the central lamp device.
Central lamp's first concept was a sphere: hence the name Sputnik, for resembling the aspect of the satellite with its antennas.
The sphere concept is cool but complex; it indeed fits requirement of 360° moving on each direction without any blind spot. Problem is that wires' joints must remain fixed. A possible solution for this concept could be a fixed transparent material like a plastic or glass orb.
For prototyping I decided to explore a simpler design of 2 circular rings with an inner part which I tried to maintain as spherical as possible.
..hence the prototype resembles more a planet with two orbital rings and I'm calling it "Saturn prototype". (Ok, it also looks like a little Dark Star.)
In time, my intention is to build quite a heavy lamp - but this multiplies the challenges, not to make it dangerous (e.g. mains AC powering in cables, steel wires strings to sustain it). These issues could be dealt with, but later in a more refined device. So I'll keep this lamp prototype as light (as in: not heavy!) as possible.
Powering and connecting these 4 devices (the central one and three wall-fixed) could result in a mess of wild wires. I decided to connect them through the sustaining wires: an elegant solution but quite a maker challenge for my skills.
This is a scheme explaining structure and 12v power line (and of course Gnd line, not shown, follows the same route). The plug is connected through one of the wall devices, runs through one of the sustaining cables and reach the lamp. Then follows its structure as shown; to reach the inner part through 4-pole pair of male-female jack plugs.
The scheme underlines mounting points (gray circles) and movement/rotation directions.
The wire chosen is flat (better torsion control, I hope), with four isolated lines of quite a small diameter (0.12 mmq) to reduce overall weight (60-80g per wire at full lenght). This could issue a problem with power current and heating. But it should improve data signals because of low capacitance.
Planned need of a minimum of 4 channels:
- power Vcc: 12v
- Signal (SCL or Rx)
- Signal (SDA or Tx)
Immediaty I took note of the risk of short-circuit of 12v on a max-5.5v AVR-pin line.
Rotational continuos movement put this issue: how to connect four rotating lines?
I decided o try a dirty solution: a 4-pole 3.5'' jack plug permanently connected that would rotate to maintain contacts. Immediately the risk of short circuit between 12v and an AVR has risen..
Device structural design of the prototype is:
- The external ring has mainly structural stability purposes; it also connects the 4 channels inside the sustaining wires.
- The intermediate ring must have room for a little stepper for x-axis and its driver circuit.
- The internal little element is where the bulb lamp accomodates, with a little stepper for y-axis and the central IC parts.
- 3 wall-fixed devices contain a big stepper motor, a reel - bobbin cylinder, a driver circuit with possibly a movement sensor.
When the lamp is turned off, another issue is probably the stepper rest situation: if it doesn't have enough inertial resistance it will let fall the lamp.
Here are some photos of the making process.
Wall devices are very raw prototype; there are many ways to make them better, in the structure and in a possibly nice enclosure: I thought of a half-cylinders concept. They also seem too big and heavy to me. In a professional product they could be enclosed inside a box in the wall and be invisible. There's lots of room for improvement!
The 3D-printed lamp structure needed some minor adjustments: holes too small, some part required to be cut, some "filet" parts detached and had to be glued together, some simply broke. The "Sfera" part gives the lamp a better aspect but 1) it is restricting space for circuit and wires and 2) it does not fulfill right the light cone-cylinder.
Surely there's work to do on the .fcstd (Freecad) files; I will not post them because they're huge (15-60 Mb) but I'll be glad to send them if someone asks me. Below are the .stl files to be printed as they are.
I intend to power this with 12v tension for the big actuators, 3 NEMA-17 type stepper motors and for the light bulb. Microcontrollers can be at 5v as much as the 2 mini steppers and the micro-slider. So voltage regulators are needed (7805) and some circuitry.
Two classics default tension values, but always hail to Keep It Simple, Stupid! philosophy.
L293 Dual-H-Bridge Drivers are needed; I choose (probably over-needed) L293E for the bigger steppers as they can manage up to 1A; for the smaller L293D. They are controlled by Attiny85 in a 2-wire configuration - this requires some circuitry but it frees 2 pins. See Arduino scheme here.
Watch out L293E has 4 more pins (hence the 20-pin package) that in the datasheet weren't clear to me; reading this forum thread explains that the chip offers possibility of measuring current consumptions (as far as I understand!). Doesn't need these, must be connected to Gnd.
A 6,3A fuse is placed on the 1st wall device, between the 12v power plug and everything else.
A pair of zener diodes (with reverse voltage in range 6v-11v) is placed near every connection joint (3 pairs on wall devices, 2 in the lamp rings) with cathode to data lines and anode to Gnd, to prevent short-circuit between 12v line.
[One of the] Worst Case Scenario can be this: I'm soldering at evening with the lamp over my head. One of the strings breaks, the lamp falls with a pendulum and crashes against a vase breaking it. The lamp structure (3D printed..) also breaks. Darkness falls.
Then some jack moves and it gets short-circuited with an I2c pin line. ALL the ICs start to smoke and catch fire. A sinister red light returns as I watch the remaining pendulum hitting my head, and setting fires in several places around the room!
At least this minimum protection circuit should prevent the latter events.
PROGRAMMING MICROCONTROLLERS - NOTES ON FUSE SETTING
First, fuse settings of the microcontrollers used.
I use an Arduino Board with ArduinoAsISP sketch (available by default in File > Examples > 11.ArduinoISP > ArduinoISP ) and a custom programming board or by breadboard and wires (see here or here). Connections for Attiny here.
So, after normally upload the ArduinoISP sketch to an Arduino Board, you will have to choose the right microcontroller (Tools > Board > ... ) and Upload Using Programmer ( Sketch > Upload Using Programmer).
ISP (In-System Programming) is a powerful tool for makers, letting you to permanently install chips on the building device and reprogramming them with only a 6 pins header.
I made my programmer board: it's usable by Arduino IDE and by avrdude. Avrdude ( here a tutorial ) is a very powerful machine-level program for AVR microcontrollers; it can do everything IDE is afraid to do.
There's a way to make and upload directly programs ( .hex not .ino ) of course. Arduino IDE can save directly .hex file, ready to be uploaded. When building programs outside this easier editor you need some more hard-coding C skills and also IC driver files (makefile); check out these tutorials if interested.
An online fuses calculator may be useful.
Atmega328P (core of Arduino Board) will be used without external crystal oscillator and (optional) with brown-out detector (BOD) disabled.
Fuses: Low E2 High DF Ext 07
Setting fuses in a linux terminal with avrdude:
sudo avrdude -P /dev/ttyACM0 -b 19200 -c avrisp -p m328p -U lfuse:w:0xE2:m -U hfuse:w:0xDF:m -U efuse:w:0x06:m
Maybe you need to change these options:
- /dev/ttyACM0 = USB port of Arduino Board (check in IDE: Tools > Port )
- -b 19200 = baud rate
- -c avrisp = Arduino Board used as ISP
- -p 328p = Atmega328P is the target
Attiny85 will be used with internal 8mhz clock.
Low 62 High DF Ext FF
sudo avrdude -P /dev/ttyACM0 -b 19200 -c avrisp -p t85 -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
- -p t85 = Attiny85 is the target
or, after loaded the sketch, when ready for closing the project and disable Reset pin:
sudo avrdude -P /dev/ttyACM0 -b 19200 -c avrisp -p t85 -U lfuse:w:0x62:m -U hfuse:w:0x5f:m -U efuse:w:0xff:m
When I'll put the stopper, I will need an extra pin an so with the reset disabled
Fuses: Low 62 High 5F Ext FF
This needs to be done with avrdude because Arduino IDE isn't brave enough. Avrdude is much more machine-level!
WARNING: after this setting, it will NOT be easily reprogrammed; you will need use a High Voltage Serial Programmer to reset defaults. I managed to build a circuit with ad Arduino for bricked Atmega (blocked at 128Khz clock!) following this tutorial. If happens with Attiny85, I think I'll give a try with this tutorial.
As a dirty and quick solution, I built a custom derivative board for a common breadboard and used pins rx and tx of an Arduino Board after removing the Atmega328P micro (I think in this way I used only Atmega16u2 usb driver present on the board). In my experience it's even a dirtier method if you think that in this way I don't use any protection to switch 5v of Arduino to 3.3v level suggested and needed by ESP device. I leave in other places ( cfr here and here ) and to other minds the debate if ESP8266 can be 5v tolerant for long time; surely, it has been for me in the programming time.
All these ICs can be programmed in Arduino IDE environment by downloading support libraries in the Boards Manager (Tools > Board > Boards Manager).
Board libraries used in this project:
- Barebones ATmega chips (no bootloader) by Carlos Rodriguez version 1.3.0
- ATtiny extra Boards by Leonardo Milani version 1.0.6
- esp8266 by ESP8266 Community version 2.3.0
Don't forget to select the right microcontroller chip (e.g. Atmega328P and not Atmega328) and clock.
There you can upload bootloader ( Tools > Burn Bootloader ).
I'm expecting the code will be simple and complex at the same time. Actuator tasks should be quite easy: move steppers - turn on/off a light - maybe dimmer it. But this job is done by 5 different devices plus a wi-fi device! And, I expect some math to calculate an horizontal movement with 3 strings attached in a pyramid-shaped point.
ESP8266-01 is connected to Atmega328P through UART (universal asynchronous receiver-transmitter) using Rx Tx pins. More important it's connected with my home router and acts as a web server; from my laptop I can open a web page at the static address
192.168.1.116 with simple interface to move the lamp.
A direct control by a linux terminal can be achieved by similar commands:
curl -s 'http://192.168.1.116/saved_position_1' >> /dev/null
Or longer (not much more complex, only longer) ones:
curl -s --max-time 30 --retry 20 --retry-delay 10 --retry-max-time 60 'http://192.168.1.116/change?length1=300&length2=300&length3=0&rotationX=90&rotationY=10&focus=10&dimmer=50' >> /dev/null || echo "Error Connection!"
Other "pages" (server requests) can be done via software - from my Raspberry Zero set up with Alexa.
For Attinys, I'm expecting to give orders but also to read sensors; not only, to give different orders each and to expect they move (almost) simultaneously for the lamp to move gracefully.
Why should I need sensors? I would like the device to know in which position currently is, because I don't like always-on devices and I know that last (and start) position can't be saved each time I turn off due to EEPROM limitations in write mode. So, sensors. Again I tried some dirty solutions..
- A variable resistor to measure rotation of the bobbin and so the lenght of cable.
- A reed sensor to detect matching rings position by rotating the lamp when starts (or, better, when it's asked to change position).
These are inexpensive solutions, require few pins (at the end of the day, actually a pin for each of the 5 microcontrollers), and I think I can manage them (see: K.I.S.S.).
Otherwise, you could use rotative sensor, accelerometers, gyro sensors, maybe a magnetic compass (this would be cool!); but for this time I said to myself: more pins, less fun.
A simple way to connect them is through I2C (Inter-Integrated Circuits), a serial bus communication using 2 wires. A well explained series of tutorials is here.
Atmega would be the "master" device and 4 attiny would be "slaves". Although we can only perform one I2C communication at a time, I found out that it's fast enough to move them (almost) at the same time.
To use I2C, libraries are needed; for ATmega328 it's a default library (Wire). For ATtiny85 you need to download a dedicated library (TinyWireS).
In first not-working tests I was very frustrated with a possible total design error: I2c is thought to be reliably working with devices in a range of meters, depending on the cable ( cfr capacitance limits at pages 36 and 57 in the protocol manual). I intended to connect 5 devices in a star configuration with three 4.5m long cables! And it seem too late to rethink it all. A big issue: I2c communication is intended for near devices. Adapting it for 4-5m distance can be tricky and unstable due to signal noise. Don't forget that in the same cable there are 12v power tension and ground, aside 2 signal wires. In fact, if the network of devices worked fine on a breadboard, when tested on the long wires didn't work reliably.
After some other tests although it partially worked, I think because of:
- more 4.7Kohm pull-up resistors on every line end
- soldered contacts and not flying jumpers on breadboard
- code hacks like repeating commands and check routines
However, these can result in slower response and put everything in risk of communication instability. Other solutions can obviously be found but for now I stick with KISS (if it works). In an initial quest for better solutions (cfr here):
- I2c at a slower baud rate (less than default 100Khz) would be better; but for my skills it requires a lot of code knowledge and work because it isn't supported and I couldn't find working solutions on the web (it's more about faster communications, like already designed 400Khz option, than slower ones). Reason for using another library rather than the original can be found here.
- an existing protocol like Manchester Encoding, thought to work on a self-clocking single wire.
- a secure but more expensive solution would be adding hardware ICs like RS485 driver or similar, or P82B96 to improve voltage level.
My (dirty) solution has been to use Rx-Tx UART configuration at a low baud rate, that maybe could be more reliable; but it isn't intended with multiple devices and therefore needs a complex configuration of commands and priorities (an entire protocol), like sending text "SET 120 040 xxx 020", and a disciplinated series of answers: "OK", "OK OK", "OK OK NO", "OK OK NO OK". This indeed would permit a "to all" command possibility like "GO". In this case for Attiny you need to use SoftwareSerial library; and also for ATmega328P because default UART bus is needed for communication with ESP8266-01. So you need to think of a double serial (cfr here ).
That's the option I'm working on: UART, 2400 baud rate, a set of communication rules. Almost the same hardware could support different communication protocols, so I could change it.
Here, a scheme of the communication concept. Essentially ATmega328P is the center (the "master") of a star-structure scheme for a UART SoftwareSerial setup. It also receives request from ESP8266-01 by another UART line (primary hardware default) and from remote controller.
Attinies occasionally use their Tx line when requested readings: other Attiny simply ignore this and ATmega328P listens.
ALEXA & HEROKU SETUP
It also has as default configuration of a push button (GPIO 18) for waking up Alexa and of a dual colour LED (or 2 single LEDs) on GPIO 24 and 25. Of course these are configurable in file
Took me some time; in particular be careful with Raspberry settings, it has to be already update and upgrade, libraries:
sudo apt-get install python-pip oracle-java8-jdk --yes
And set up an external USB speaker as default (not HDMI audio output, not 3.5 jack) -- after lots of terminal time I came up with a simple click on the GUI sound settings, choosing the Audio Adapter as "default".
AlexaPi install mainly it's very easy, few lines in terminal:
cd /opt sudo git clone https://github.com/alexa-pi/AlexaPi.git sudo ./AlexaPi/src/scripts/setup.sh
After 45-60 minutes of install scripts,
And it's done.
Now, there are a LOT of methods to control a custom device with Alexa, involving different services - some of them are not free of charge. After some research I came across Heroku multi-language platform following this project. Official tutorial for setting up a web app in Python can be helpful.
Heroku works with a git repository method to upload app. Open an account and download the terminal program. Then, every time you need to change code, you follow this passages:
cd projectDirectory heroku login nano Procfile nano requirements.txt git add . git commit -am "and beyond" git push heroku master
Then you activate a Dyno as a web app or a worker:
heroku ps:scale worker=1
heroku ps:scale web=1
VOICE USER INTERFACE (VUI) DIAGRAM
Here the voice user interface flow diagram I'm using in my Alexa Skill Sputnik-Control, in pair with the python app on Heroku.
ACTUAL STATE OF THE PROJECT
2-23-2018 At the moment, as you can see in the video log, I'm at the work-in-progress phase. And I'm waiting for two big stepper delivery (aaargh!).
To do next:
- mounting and make move freely the devices
- soldering circuitry + extras (e.g. stopper solenoids, add a sensor for slider's end-of-run)
- test structure and code on the mounted wall prototype
- rectifying constant variables (e.g. steppers speed and steps-per-revolution, cable length maximum and minimum)
- testing again the code communication protocol (find a low-speed I2c protocol!)
- improving code: introducing some math to permit xyz movements (e.g. "Alexa, ask Sputnik to move 10cm on the left")