Posted in Rant, The downside of Opensource on March 20, 2019 by asteriondaedalus

So, OpenMV M7 from ebay.  Watchout!

The price compared well with the OpenMV store, which reported out of stock on M7.

So, I bought of ebay.

The problem, it appears there is a need to register the boards with OpenMV to get access to the OpenMV IDE. 

The board from ebay is registerable BUT it costs $15 per board, in addition to the purchase price, if it doesn’t come registered via OpenMV.

I otherwise assume that the boards from OpenMV come pre-registered, since the registration make sense.  It makes sense because open hardware is a way to no make money, since you give up your IP and it then gets copied.  Adding board registration, though not really open sourcy, seems like a good way to make sure the software side stays viable. 

Sure, copy and sell the boards.  You don’t have to pay a licence BUT the user buying your board does.  So, why charge the same as a registered board from OpenMV?

Rip off?

Not really, the OpenMV M7 is USD$65, I paid AUD$61 then AUD$21 to register so that’s AUD$82 which is AUD$10 cheaper than the USD$65.

The scary part being what, if like FDTI chips, you couldn’t register clones. Now that would be saucy.


Warm and cosy!

Posted in 3D Printing on March 16, 2019 by asteriondaedalus

So, on order is a thermostat and a PTC constant heat incubator heater with fan. That should allow me a means to keep the air around the printing warmer.


Posted in 3D Printing on March 16, 2019 by asteriondaedalus

So, I was having too much trouble with the extrusions warping and shrinking. Part of the issue was, I suspect, the aircon. So, the room was too cold.

The other, well, I assume the plastic reel that comes with the printer might have been low quality OR had absorbed moisture (there is some chatter on that on the web).

In any event I looked around for a box to stuff the printer into. I did almost go for a couple of 19 inch boxes at the auctions, but they went too fast.

So I opted to get an 11U 19 inch box from a mob from interstate. I can recommend them, they are very very helpful. I did have them triple check dimensions for me before I bought the item.

It is a perfect fit for the flashforge finder! The flash finder is a 420mm cube. The printer slides in the open door. The two side panels come off for access as well. The height leaves room enough for the feed tube. Did I say perfect!

All I need do now is sort a small fan heater to warm the interior of the box. I will sort a temperature control et cetera.

Only downside? Faraday shield! So, I can’t connect by wifi no more no more. So, I need a long USB cable. No matter.

Give me a break!

Posted in Robotics, Sensing on March 8, 2019 by asteriondaedalus

So, you know the story behind OpenSprinklette.

Why bother with an raspingdoodleberry Pi and a “open” hardware controller for sprinklers of the OpenSprinkler, for $200 all up, if you can build a controller for sub $20 using a UNO based ESP8266 with a quad relay board, or a nest ESP8266 with single relays.

Well, StarGazer is US$980! Or, at current rates, AUS$1,390.91!

When all you need is a OpenMV M7 at $60, with a bunch of printed April Tags. Oh, and some trigonometry.

Two OpenMV M7 on their way to my parts bins.

My CMUCAM5 Pixy is getting old, but I wonder if I can sneak some of the OpenMV libraries over to the CMUCAM?

My PX4FLOW is looking sad. This is because its the same price breakpoint as the OpenMV M7. The PX4FLOW is only for Optical Flow tracking. The OpenMV can be used at least for Optical Flow, but also for a range of other applications as noted on its web page.

Too easy!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

So, over a vodka and coke I did hack up the code to allow for auto config of group gadgets.

Works a treat.

Basic process is boot/reboot home server. That starts the node-red with global data empty.

Then turn on opensprinklette gadget one at a time. Either lwt or herald will log the meta-data for the gadget into the global array. The idea you set the group or unit ID (1..4 or 0..9 respectively) by turning on the gadget to associate the gadget with its location.

In the global space in node-red there is then 4 group var and 10 unit var. Sure, could have used arrays but saved on string concat or parsing since the term “group1” is, for example, used in the title of google calendar event for example. Saves on index bounds checks etc. Given the design decision was to allow 4 groups (4×4 relays) and then 10 units (10×1 relay) it was a trade-off.

The user then turns on gadgets around the yard or paddock to associate a location with a gadget. User does not have to know the chip id of the gadget per se. For example, if you want group1 to be the quad relay gadget managing the four solenoids controlling water to your back yard, then you turn that quad unit on first, before any other quad unit, after server boot/reboot. And so on. Think of it as a method of loci. That is, user associates the group or unit with a location.

I will slowly add a HMI so that location can have a description field, though that will be added by node-red. The gadgets will never have any idea of their physical location.

While the server stays up, the gadgets can go online/offline without losing their loci. They only lose that if the server goes down.

To test this, I programmed two WEMOS D1 R2 (UNO style) with quad relay version of code.

I was able to power up gadgets and then see both boards as group1 and group2, respectively, in the order that they were powered up.

If I held down reset (to fake a brown out) the lwt, for each gadget, was generated by the MQTT server. The online status of the gadget was then set to offline as expected.

Once I let reset go on the gadget, the gadget re-started and the online status of the gadget was reset to online. This is accomplished because the herald topic is published on successful start up. The herald is an object that looks like this:

gadgetType: 2
gadgetId: 12678832
online: 1

If it helps, the “online:” flag is 0 when lwt generates the same object. I simply re-assign either the herald or lwt object for the gadget to the global array entry for the gadget in the node-red global space.

The problem, for the moment, is if the server goes down then up. Unless you power off then on the gadgets, after the servers comes back up, they will not be registered when server comes back up.

If you reboot the server, a sound-off topic, at the server, to all connected gadgets will help pick up and register all gadgets BUT they will register in order of message received by node. The MQTT server controls the order (I guess) of topics out to subscribers. That means, for the moment, they will not be in assigned by loci.

So, I need a bit of work on the problem of server brown out. Likely, it is simply using the filing option for context. I need to add an un-register function in that case. There will be a time when a gadget dies permanently and needs to be removed from the register.

Yes, it would otherwise be bad form to manage the global gadget data that way. Since I am also looking at distributing the gadget meta-data, there is still a design effect to get through.

For now the config mechanism allow me to now move to glue the calendar code and sprinkler driving code together for the first time.

Down hill run now.

And my vodka and coke has evaporated!

To bed!

Almost there!

Posted in OpenSprinklette on February 10, 2019 by asteriondaedalus

Opensprinklette closer.

Been a long haul with some distractions drawing me away.

The ESP8266 code is done. Tested on WEMOS Uno clone, with DIYMORE quad relay board; WEMOS D1 Mini with single relay shield; and that more industrial single relay ESP8266 with single optical protected input.

I am working on a way to configure the clients into the node-red flow by simply turning them on in the order you want to assign them to either groups (quads) or units (single relay).

There is a quirk with the lwt side, since it’s 50/50 that a lwt comes through before the client pumps out a herald message (here is for the plebs in the audience).

I catch this since lwt is essentially offline message and herald online message, so I have both lwt ahd herald pumping out a JSON record of type (group/unit), ID (esp8266 chip id), and offline (lwt) or online (herald) flag. That way the gadget gets registered on power up either as offline or online. The herald comes through lickity split after the lwt so once up it is fine.

There will be two nodes that you hook lwt and herald messages from mqtt into. That will setup config in global context. One node is for units and the other for groups. This is inline with node-red design rules BUT also makes sense because you might only have either quads or units in a minimal setup.

The parser function, for decoding titles of google calendar events, into sprinkler activations, is well and truly tested. I still need to pull apart the duration of the calendar event to provide a millisecond value for the duration. Once that last parsing job is sorted I will be in a position to test and then deploy into the node-red community. The esp8266 code will be in github.

I will likely hold off for a couple of months while I thrash the system on my home sprinkler system. To catch any other quirks.

Once that main work is closed off, I am planning to work on code for control by android phones. Principally using the node-red hmi widgets. One thing though is I will look at a lightweight distributed key:value store to pass gadget meta-data around.

I don’t wan’t necessarily to drive everything from the home server. I have an evil plan to use RAFT for the fun of it, and as there is bugger all metadata to manage (so the metadata sits in two arrays, 4 entries for quads and 10 for units). Even RAFT might be overkill but I want to get my head around it in any event.

Finally! But …

Posted in 3D Printing on January 25, 2019 by asteriondaedalus

Looks good right! Nope. Its not a parallax trick, that downwards slope appearing of top edges at front is shrinkage. The obviously failed bits shrunk away from the plate. The large printing stayed stuck to the plate but shrunk back into the plate.