jun 052017
 

Via Adafruit kwam ik bovenstaande video van KaneFernandes Design, een 19 jarige student Product Design aan de Middlesex Universiteit in London. De titel is een beetje misleidend, er staat “360º Smartphone Camera Drone Rig using Arduino Uno & XBEE“, er wordt niet echt gebruik gemaakt van een drone, maar van de motor + propellor van een drone. Maar inderdaad, de smartphone “vliegt” om het object heen. 🙂
Daarmee is het project niet minder mooi, vooral ook omdat de video laat zien hoeveel (denk-)stappen er aan het eindproduct vooraf gaan.
De eerste versie maakte heftig gebruik van duct tape, ik kan tegenwoordig niet anders meer dan meteen aan Astrid Poot denken als ik zoiets zie, maar de volgende versie werd een stuk degelijker en technischer. Maken is zeker niet hetzelfde als wat knutselen met spullen!

Hoe dan ook, het is een mooi gedocumenteerd voorbeeld. Een van de resultaten die ermee gemaakt zijn:

Deel dit bericht:
apr 102017
 

Als het in het onderwijs in Nederland over “programmeren” gaat worden eenvoudige vragen al heel snel ingewikkeld. Dus een vraag als “Welke programmeertalen zouden onze leerlingen/studenten moeten kennen?” (bron) is niet helemaal zonder risico. Immers, je moet dan gaan nadenken over het doel dat je daarmee hebt. Wil je ze leren programmeren? Of juist coderen? Of software ontwikkelen? Ik ga niet eens proberen naar bronnen te linken die ze op één hoop of op juist heel verschillende hopen (en dan per bron ook verschillend) gooien.

Dus laat ik het maar even veilig houden in deze blogpost. Zo’n 9 jaar geleden vroeg ik me af welke programmeertalen ik allemaal zou moeten leren. Zoals ik toen beschreef:   Basic was mijn eerste kennismaking met programmeren, maar daar kon je (toen) zo weinig mee dat ik er niet veel interesse voor had. Op de universiteit leerde ik Turbo Pascal om daar vervolgens nooit meer wat mee te doen. Daarna kwam ik in de Windows omgeving en Visual Basic (binnen Office!) en Active Server Pages (ASP) terecht. Mijn eerste kennismaking met JavaScript was in de browser, ASP werd vervangen door PHP toen ik weblogtools ging gebruiken op basis van die taal. En daarna werd het een opeenvolging van “wat heb ik nodig”. Zo kwam er een beetje Python bij, een heel klein beetje .NET en eveneens een klein beetje Java. Dat was toen. Sindsdien zijn er dingen gewijzigd en gelijk gebleven.

Lees verder….

Deel dit bericht:
apr 072017
 

What happens if you take a LoRaWAN node with you in a train while you travel across the Netherlands for about 2,5 hours? I did not know and wanted to find out today because I had to be in Zwolle for a meeting.

So I charged a big external battery (with 2 USB ports), drilled a couple of holes in a plastic container to guide through the micro-USB connectors, and put in some bubble foil inside for safe transport. I drilled another hole to connect the external antenna for the LoPy node. Besides the LoPy, I put the Marvin in the box, with the temperature/humidity sensor on the outside of it. Not that it really mattered, today was going to be about finding gateways while I was on the road.

Things did not look good for the experiment though in the morning. The Things Network (TTN) backbone was acting up again. That was a bummer, because I still had to change the code on the LoPy. It had the code installed for the Circuit Playground and I wasn’t planning on bringing that also. So I changed the code to a simple “send a number every 30 seconds” but was not able to test it before leaving for the train.

To make matters more balanced: I decided to have the Marvin connect to the KPN network (still got 60 days left on my free trial), but the Hookbin.com server decided that today was a good day to refuse to work. And I needed a place to store the data sent by the Marvin. Luckily I found loggly.com another site that you can use as a destination for KPN nodes. I think it is better than Hookbin btw because it keeps more records and even the free plan should be enough for most people. Another nice thing was that Loggly also can act as an HTTP-integration for TTN, so I could collect both the data sent via KPN and the data sent via TTN in one single place. Quick tip: Loggly provides you with an http:// url for the endpoint, KPN doesn’t accept http:// but you can simply change the provided url to https:// and then it works.

OK, into the train. I wasn’t really sure what to expect. A train means lots of metal and a fast moving object (and nodes).

Lees verder….

Deel dit bericht:
apr 052017
 

One of the challenges left with regards to the LoPy was to find a way to actually connect sensors to the node. I had little luck with the DHT11 temperature/moisture sensor (one of the drawbacks of MicroPython over regular Arduino code is the lack of libraries) and didn’t have any I2C sensors lying around. But I did of course still had the Circuit Playground by Adafruit and I knew how to talk to that one from another device using the hardware serial RX/TX connection because I had already connected it to a micro:bit that way (the posts are here, but in Dutch).

So surely it should be possible to connect it to a LoPy and send the sensor data to The Things Network (TTN) that way? Is was. Not as easy and simple as I had hoped, but in the end it worked. Since it is rather a complex structure, I made a small graphic to explain how all the parts go together.

Let’s start with the easy parts: I have got a LoPy Nano Gateway up and running. That is not a full compliant LoRaWAN gateway, but it takes care of receiving messages send via LoRa / 868 Mhz and relaying them, via WiFi, via my WiFi Router, the internet, to the The Things Network (TTN) backend. That is the regular part.

On the right end lower corner, the action starts with the LoPy Node. It is connected via two cables to the Circuit Playground (CPG). One cable goes from the TX port of the LoPy Node to the RX port of the CPG. The other one goes from the TX port of the CPG to the RX port of the LoPy Node. The LoPy Node sends a signal (a digit ranging from 1 to 10) over the serial connection to the CPG. After the CPG receives the signal, it reads the three build in sensors for light, noise and temperature. It then converts the values to a 12 byte HEX string value and sends that back over the serial connection toe the LoPy Node. After sending the signal, the LoPy node waits a bit, giving the CPG time to return the value, then it reads the values and sends that via LoRa to the first available gateway, in this case the LoPy Nano Gateway on my desk.

After the gateway has delivered the messages to TTN, a Payload function translates the received value back into three individual values. It then send them, via the Integrations option, to the Swagger server where it the is available in JSON format. See, easy peasy. 🙂

I uploaded all the code to Github. You can find it here. The code in the LoPy-flash folder is (of course) intended for the LoPy Node, the code in the Circuit Playground folder needs to be uploaded to the CPG via the regular Arduino IDE. I made some changes to the LoPy node code provided by Pycom: I added the option to have the LoPy Node also connect to your local WiFi. Not necessary, but it makes it easier to debug/connect. If you leave that info blank, it will just ignore. Also, if you take the node outside of the range of you WiFi network, it will just ignore it. Another thing that I changed, is the use of config.py for the Node, so that you only need 1 place to change all the info. Finally I choose OTAA instead of ABP as the authentication for the node.

Lees verder….

Deel dit bericht:
apr 032017
 

Laat ik beginnen met de breed gedragen constatering dat het werken met paper circuits toch nog best heel wat moeilijker is dan dat je zou denken als je de filmpjes die online staan ziet. Wat dat betreft is het ook maar goed dat ik 5 rollen van 30 meter besteld heb, want er zal nog wel wat tape “verbruikt” worden.

Maar…de opmerking dat ik natuurlijk na het weekend ook wel een paar voorbeelden wilde hebben om te laten zien, was voldoende stimulans om te volharden.

Ikzelf was er voor het debuggen, als mensen een voorbeeld zoeken van een debug-activiteit die niet met programmeren te maken heeft: laat leerlingen met paper circuits aan de slag gaan! 😉

Ik weet zeker dat ze dan ook leren om nauwkeurig te werken en planmatig te werk te gaan. Want als je niet nauwkeurig bent, dan is je stroomkring al bij de eerst bocht onderbroken en als je niet planmatig te werk gaat bestaat je project vooral uit frustratie om led lampjes die verkeerd om zitten of stroomkringen die niet sluiten.

Maar natuurlijk is het ook gewoon leuk. Waar Marit meteen aan het tekenen sloeg en begon met een mooie voorkant, dacht Niek na over parallelschakelingen van ledjes met aparte knopjes per led en combineerde Josine bestaande kaarten met ledjes en zorgde voor batterijhouders (van papier).

De kopertape die we hebben blijkt tweezijdig te geleiden, dat is handiger dan tape die alleen aan de bovenkant geleidt. Het vastplakken van leds met plakband blijkt niet zo handig, het contact is minder sterk dan nodig, beter is het om ook daar kopertape te gebruiken.

Lees verder….

Deel dit bericht:
mrt 192017
 

Since some of the people that inspired this weekend project can’t read Dutch, I decided to do the follow up of part 1 / deel 1 in English. That first part, posted yesterday evening late showed work in progress. Today, the Panda Ballerina was completed. Before I show you the end result, I wanted to go into the steps involved in a bit more detail.

Like I mentioned, the Paper Panda Prototype by Jeannine Huffman was the initial inspiration. That project is already a year old, but I think it was Per-Ivar Kloen that tweeted about it recently. That combined with the tweet by Sarah Magner determined the theme: a Panda Ballerina.
Now both the Paper Panda and the Ballerina use copper tape / paper circuits, my order of tape is still on its way, so that wasn’t possible yet, but I did receive the ATtiny85 chips, although in a different form factor, in my case as a DigiSpark ATtiny85. We had some TowerPro SG90 servos and a couple of LEDs, so the idea was to create one using thin plywood.

Template
First step was to come up with a template. Now I have to admit, Googling one is no problem for a private setting, for say classroom use it is best to use one where you are more sure about the rights to re-use and make derivative works then I am for this one: I could not find the original creator. So, draw one yourself if you want to be 100% sure that it is OK. After you draw you figure, you have to separate the two parts. In my case I made a copy and using the lasso tool, I erased the body for one copy and the head for the other copy. Then I added something neutral looking that could act as a nek. For the next version that part is going to be smaller and less visible, but you need something to attach the servo to.

Print, transfer to plywood, cut the plywood with a jigsaw, carefully smooth with sandpaper and add color. We glued a second black/white version to the wood because that allowed the drilling of holes for the LEDs in the head without later seeing the actual LEDs.

Lees verder….

Deel dit bericht:
mrt 182017
 

Vanaf het moment dat ik via Twitter het Paper Panda prototype voorbij zag komen, kwam het op mijn “eens keer uitproberen” lijstje terecht. Toen ik daarna (via deze tweet) een ander vergelijkbaar voorbeeld met een ballerina zag wist ik dat het dan een Panda Ballerina moest worden.

Omdat de kopertape nog niet binnen is, maar de ATtiny85 wél, kon ik aan de slag. Nou ja, ik, het werd een weekend familie project waarbij de ene helft van de familie het figuurzaagwerk voor haar rekening nam en de andere helft met de DigiSpark ATtiny85, een TowerPro SG90 servo en een paar LEDjes aan de slag ging om te kijken of we dat deel voor elkaar konden krijgen.

De deelresultaten:

 

Zoals je hierboven kunt zien zit het geheel inmiddels bijna in elkaar. Het boren van het juiste gat in het lijf (zodat de servo haast vanzelf vast klempt), de extra dunne en flexibele draad aan de LEDs en de programmering van de ATtiny85 werken in principe. De servo maakt nog niet helemaal de juiste beweging, dat betekent dat ik het aantal graden in de code nog moet aanpassen.

De twee LEDs zitten nu zonder weerstand in serie aangesloten. Ze zijn op het moment feller dan toen ik de schakeling met losse kabels opgebouwd had. Zal dus aan de weerstand van de verbindingen liggen. Voor wat betreft de kabels was het even kiezen tussen het gebruiken van een prototype-board alleen voor het netjes aan elkaar verbinden ervan of bij elkaar pakken, soldeer erover en krimpkousje. Het werd dat laatste.

Morgen dus herprogrammeren, het kabeltje van de batterijdoos die (grrrrr) afbrak in de doos netjes solderen (zit nu provisorisch vast), het gezichtje er op plakken, het geheel vast aan het doosje en dan is dit weekendproject officieel klaar (en het weekend voorbij).

Deel dit bericht:
 Reacties uitgeschakeld voor Weekendproject: Panda Ballerina ATtiny85 – deel 1  Tags: , ,

Te lui om te solderen

 Gepubliceerd door om 23:37  Arduino, Hardware
mrt 162017
 

Vandaag kwam een pakje binnen met een aantal DigiSpark ATtiny85 ontwikkel boards. Toen het bordje in 2012 op Kickstarter verscheen betaalde je 33 Amerikaanse dollars voor 3 exemplaren incl. verzendkosten. In 2017 betaal je via AliExpress het enorme bedrag van €10,60 voor 10 exemplaren incl. verzendkosten.

Op het bordje zit een ATTiny85 chip. Voordeel van de DigiSpark is dat je geen aparte programmer nodig hebt. Er zit een kleine USB aansluiting (“gewone” USB maar klein omdat er geen behuizing omheen zit, zie de foto’s hiernaast) op en vanuit de Arduino IDE compileer je het script en zet je hem er op. Er zitten 6 I/O Pinnen op (2 zijn gebruikt voor USB), er is 8kB Flash-geheugen beschikbaar (ongeveer 6kB nadat de bootloaderer op staat) dus scripts moeten vooral heel klein en eenvoudig zijn. Je hebt de beschikking over I2C en SPI, PWM op 3 pinnen (meer mogelijk met Software PWM), ADC (Analog-to-Digital Converter) op 4 pinnen, een Power LED en een onboard Test/Status LED (op Pin 0).

Zoals je op de foto’s bij het bericht ziet krijg je headers bijgeleverd die je naar wens er op kunt solderen of niet. Ik was daar vanavond te lui voor, dus heb ik (nadat ik eerst het blink-script getest had met de ingebouwde LED) een LED met weerstand gewoon aan elkaar gebonden en de pinnen rechtstreeks in respectievelijk pin 3 en de ground bevestigd. Zoals je ziet werkte dat.

Ik vind deze combinatie handig omdat het qua programmeren net weer een stukje gemakkelijker is dan een kale ATTiny85. De kosten zijn niet echt hoger, ook voor de kale chip betaal je een euro (en dan moet je een programmer aanschaffen) én dit is nog steeds plat genoeg om bijvoorbeeld in een paper circuit te verwerken. Voor de installatie-instructies, zie deze pagina. Je kunt de Digispark ook op een batterij laten werken en dan de 5V of de VIN aansluiting gebruiken. Het hoeft dus niet persé aan een USB aansluiting.

Deel dit bericht:
 Reacties uitgeschakeld voor Te lui om te solderen  Tags: ,
mrt 112017
 

Toen ik afgelopen week met de micro:bit en de Circuit Playground (CPG) aan de slag ging, lukte het me niet om via serial een verbinding tussen de CPG in de richting van de micro:bit op te zetten in combinatie met de CPG library. Zónder die library kon ik dataverkeer beide kanten op realiseren, zodra ik de library initialiseerde met CircuitPlayground.begin(); ging er geen verkeer meer de kant op van de micro:bit.

De oplossing bleek te liggen in het gebruik van de hardware serial aansluitingen van de CPG in plaats van software serial waarmee ik aan de slag was. Tot nu had ik alleen met de hardware serial gewerkt als het ging om communicatie via de USB-poort van een Arduino. Dat deed ik dan via bv via Serial.println("Setup complete"); waarbij ik dan in de Serial monitor op mijn computer de output kon zien, ideaal voor het debuggen. Als een Arduino board een hardwarematige seriële aansluiting heeft (soms hebben ze er meer dan 1), dan kun je de andere hardwarematige poorten ook gebruiken. Die heten dan achtereenvolgens Serial1, Serial2 etc.
De hardwarematige poorten werken prima samen met de CircuitPlayground code. Ik heb een nieuwe versie van het script op Bitbucket gezet. In CPG_Serial_Slave.ino staat de versie met de softwarematige seriële poort in CPG_Serial_hardware.ino staat het script beter werkt en dan de hardwarematige seriële poorten gebruikt. De code op de micro:bit is nog steeds dezelfde microbit-Serial-Count-Master_and_Slave.hex die je hier kunt vinden.

De werking is als volgt: nadat beide script op respectievelijk de micro:bit en de CPG geladen zijn wachten de boards op een start teken. Door op de B-knop van de micro:bit te klikken begint het script daar. De micro:bit laat een tekst zien op het display waarin aangegeven wordt dat eerst een 0 (nul) naar de CPG gestuurd wordt. De CPG wacht totdat er data via de seriële lijn binnen komt. Is dat het geval, dan wordt de string die ontvangen is omgezet in een getal. Er worden dan evenveel Neopixels aangezet als het getal hoog is. Dan wordt hetzelfde getal terug gestuurd. Dat lijkt zinloos, maar de micro:bit wacht op het terug ontvangen van een getal voordat hij verder gaat, zo blijven beide processen in sync. De micro:bit laat zien dat hij +1 bij het getal optelt voordat hij het terug stuurt. Dat gaat verder totdat het getal groter is dan 10. Er zijn maar 10 Neopixels, dus reset de micro:bit het getal dan naar 0 en stuurt de 0 door zodat ook op de CPG alle Neopixels uitgeschakeld worden.

Ook dit was een test om het communicatiemechanisme beter te begrijpen. Interessant wordt het als ik nu een telefoon via Bluetooth aan de micro:bit koppel en instellingen draadloos door kan geven, of een WeMos D1 ESP8266 chip (kost zo’n 3 euro) om er voor te zorgen dat de CPG alsnog over een Wifi-verbinding kan communiceren. Dat zou via Firmata moeten kunnen, want ook die kan zowel via USB als via de hardwarematige seriële poort aangestuurd worden. Wordt dus later vervolgd.

Deel dit bericht:

Twitterarchief 09-03-2017

 Gepubliceerd door om 06:55  Arduino, Twitterarchief
mrt 102017
 

Deel dit bericht: