Archive for April, 2017

Tax return is in

Posted in Chapel, ODROID is wonderful, ODROID-C1, ODROID-XU4, Parallel Talk on April 30, 2017 by asteriondaedalus

Well late really, last two years after tax department started writing letters.

Serve them right as I got a quite hefty lump sum out of it.

So, after agonising over what to do about GPU based system, I decided I am only dabbling so I opted to simply get an ODROID-XU4 so that I can at least run OpenCL under Python.

Mind you, after toying with Chapel on my quad-core Odriod C1, I will be interested in the Octa-Core Xu4.  I did splurge and get an 32GB eMMC 5.0 with Linux.

I went this way as even now the Jetson TK1 is available (as its now obsolete) in Australia, I am rather more interested now in Chapel.   Not to mention that Chapel appears to be a better approach than Cuda.  That is the appeal, you can take your Chapel code and just change the underlying engine.

So, my cluster will be one ODROID-XU4 and four ODROID-C1.  So, 24 cores all up (not taking the general purpose GPU on the XU4 into account).

Oh, and the 18 cores the Parallella adds.  You do know there is an Erlang for the Parralella don’t you?

I am in parallel programming heaven.

The thing that makes it all possible is the 9 port POE switch and a gaggle of active POE splitters (48V down to 5V) – you don’t need n-power packs on your wall.

Don’t forget TTY+ (MPutty) or some other multiple session tool.

Built into the guts of an old game PC case my mate gave me, so the wife will never know.

If I need more grunt a NVDIA card maybe later, in an 8-core PC, maybe.

However, PhD submission draft this weekend so dabbling is all that I will have time for.

Here’s the theory …

Posted in Arduino, Beaglebone Black, C.H.I.P., General niff naff and trivia on April 29, 2017 by asteriondaedalus

… straight forward really.

MOOS-IVP happily compiles and runs on on of my Beaglebone Blacks.


Sooooo, no stretch (pardon the pun) for MOOS-IVP to fit onto a C.H.I.P.!


Both are 1GHz processors with 512M of memory.

The standard approach, in any event, is run MOOS-IVP on the linux board and have an arduino interfacing with the hardware.

Of course, I am running against the AIO:

You could just as easily run against a raft of other boards, such as:

Or even a Parallax Propeller board!

That would all depend on what you are offloading to the hardware layer.


Posted in The Downside of software development on April 24, 2017 by asteriondaedalus

Microsoft are so lame.

Go figure, I bit the bullet and decided to play with MRPT.  The straightforward approach was to run it on my PC so, yes, yet another version of Visual Studio (2013 this time).  It is always with great trepidation I grab yet-another-version of VS as MS seemed not to manage the interaction between licencing between versions.  I have had problems due simply to installing two different versions of the toolset.  The problem was amplified because CMAKE is being used. So, if I mention CMAKE in the help room, when discussing the context in which the error is raised, some dopey MS/VS guru will dump on you for using OPENSOURCE software (CMAKE) even though you’re using the FREE version of VS.

In any event.

Stung again somewhat.

Install taking a stupid long time.


Its installing all the components I told it not to in the original panels of the wizard.

Why on earth do I want the Windows 8 for phones SDK?

Price drop …

Posted in Design rather than hacking on April 22, 2017 by asteriondaedalus

… probably as the technology has waned.


I bought a PIX4Flow for dirt cheap as the problem with encoders on the rock crawler is that the wheels spin or are off ground (dependant upon pose) etc. so something trickier needs be done with the odometry.

The problem with mouse sensors is that they are only good well lit environments and cannot be used closer than 30cm to the surface – apart from other quirks.

The problem for the PIX4Flow, however, is the following velocity over ground by focal length of camera by ground distance.

Ground Distance 1m 3m 10m
16mm 2.4m/s 7.2m/s 24m/s
8mm 4.8m/s 14.4m/s 48m/s
6mm 6.4m/s 19.2m/s 64m/s
4mm 9.6m/s 28.8m/s 96m/s

The PIX4Flow, of course, comes with a 16mm f/l lens so a maximum speed with a ground distance of 1m is 2.4m/s which is 8.6km/h (think jogging as opposed to walking at around 5km/h).

That’s okay for a rock crawler except for the 1m story.

Now, I was bamboozled by the equation for calculating the max velocity (since it seemed unkempt in it’s use of precedence).

So a simple plot shows how the problem pans out.


So, if I use the 16mm f/l, at say 200mm, my max velocity would be 2.4x with x = 0.2m so 0.48m/s (or ~1.7km/h) which is roughly a 3rd of a average walking pace of 5km/h.

Of course I ordered a 3.6mm f/l lens from Aliexpress for $5.

The 3.6mm f/l (approximating to 4mm) would be 9.6x or 1.92m/s or 6.9 km/h at 0.2m (a brisk walking speed).  Presumably, it would be slightly better than than as, from the graph, the curve for the 3.6mm f/l would be slightly steeper than the curve for the 4mm f/l.


So, a quick plot of the 1m column (which coincidently provides the slope of the lines in the previous graph) and then best fitting the graph with a power based curve (extended by one unit) and we can estimate the slope of the 3.6mm f/l curve to be 10.7.  That should approximately be 2.1m/s maximum velocity or a healthy 7.7km/h.

Again, fine for a rock crawler … assuming the $5 lens turns up, is what it says it was on the add, et cetera.

Fingers crossed.

Of course there are algorithms out there for slipping, sliding and drift using EKF.


It never rains …

Posted in OpenSprinklette on April 22, 2017 by asteriondaedalus

… and I have just got back to my web-based sprinkler to find, with writing papers for conferences and work deadlines, my google api tokens were dodgy.   The reasons are clearly explained in the api documents.

So I deleted the credentials and created a new set.  All working fine again.


I can get the json response from the calendar on the debug window.

I put a json function in to turn it into a jsp object.  The output should be stringified and displayed in the debug panel but nothing appears.

I have two separate flows, one for start of the event and one for the end.  If I put a json function on the start, neither of the start or end events are displayed.

What’s worse, taking out the json function and going back to a straight through flow also no longer works.

Not getting the token expiration warning so it isn’t that problem anymore.

To get it going again, with the json function included, I needed to stop and then restart the node-red server.


Posted in Help Request on April 5, 2017 by asteriondaedalus

Why have I strange red circles now on my Android desktop?

Just floating above everything.  Not reacting to anything?



So, didn’t work out what caused it.  A phone reset cleared it.

I had Planet’s Position app running at the time (the thing almost looks like a planet orbiting doesn’t it).  However, I uninstalled the app and reinstalled it but the circles did not appear again.  So, likely too much going on to pin it down to one thing or the other.