julia on ARM for a drone

[Jeff Waller]

Does update last month and the discussion about arm nightlies mean that ARM is generally supported now?

I have a specific purpose in mind that doubles down on the difficulty, however.  The install method need not

be by RPM, but though the processor is an ARMv7,  it's more specifically Cortex-A9, and is not related to Redhat

or Rasperry, but rather the OS is Yocto Linux; which is an interesting project -- it's a distro built from the result

of a cross-compilation framework paired with a bunch of metadata describing the processor.  The idea is that

if one can describe the processor, then the distro can be tailored to it.

Trying to get julia compiled within the openembedded framework might be a good proj itself, but my specific purpose

is because that distro is used by this drone, and I feel that (would like that) Julia could well play a part in the control

software.

You know, any sort of tips would help; hey I just try one of the nightlies and see what happens.

[Jeff Waller]

An update:

It turns out that the default linux client compiled for ARM does work with a few modifications.  It is indeed

slow to JIT-compile, (on the order of seconds), but is fast after that.  See randomMatrix.txt in the gist, for

exact measures, but for example rand(100,100) takes 1 second the first time and then 0.0005 seconds subsequently --

that's quite a speedup.  Likewise, svd of that 100x100 random matrix is 3 seconds and then 0.05 seconds

afterwards. 

Also, of course, I tried using node-julia and that was difficult, but I managed to get that working too.  Firstly, I had

to add -march=armv7-a to the compile step to allow use of C++ std::thread to be successful; apparently this

is a known bug of openembedded, and not an issue with Julia. However, I also had to add -lgfortran and -lopenblas

to the link step to satisfy the loader which is reminiscent of the error I had when I first tried to get thigs working on 

linux in 2014.  This is not the same thing but feels possibly related.  I also had to create a symbolic link for gfortran

as only the specialized version (libgfortran.so.3) existed; ln -s libgfortran.so.3 libgfortran.so; that should probably

be fixed.

All but 3 of the node-julia regressions worked once I increased the default timeout time.  You can see the relative

speed differences between an OS/X labtop and the drone in the gist as well.  Some of the timings are comparable,

some are not.

I believe the large difference in time is due to not only the processor being slower, but the (flash) filesystem as well.

Exec-ing processes on this drone takes a very large amount of time (relative to normal laptops/desktops).  The memory

is limited too (512 MB), so you really have to be careful about resources.

[Viral Shah]

Making sure I understand correctly, were you using the distribution on julialang.org/downloads? If you had to do a few things to get it to work, can you file issues? I personally would love to see more such applications and that was the motivation to have an ARM port in the first place.

Compile time is a huge issue currently on master, and more so on arm - but is not arm specific. This will get chipped away with all the work that Jeff, Keno, Jameson, Yichao, and Oscar are doing.

-viral

[Jeff Waller]

On Monday, February 15, 2016 at 5:55:19 AM UTC-5, Viral Shah wrote:

Making sure I understand correctly, were you using the distribution on julialang.org/downloads? If you had to do a few things to get it to work, can you file issues? I personally would love to see more such applications and that was the motivation to have an ARM port in the first place.

Sure can.  I'll answer some of this now.

The first thing to note is a lot of the workaound was a result of the arbitrary nature of this distro rather than ARM per se, however, at the same time expect that ARM will more

likely be associated with previously unseen OS since it is likely to be tailored to the processor and the processor is tailored to the task/device/application.  In this case, the 

processor was likely chosen for its ability to work at low wattage while still delivering enough CPU to do the task.  Here it is:

3dr_solo:~$ cat /proc/cpuinfo

processor       : 0

model name      : ARMv7 Processor rev 10 (v7l)

BogoMIPS        : 1988.29

Features        : swp half thumb fastmult vfp edsp neon vfpv3 tls

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x2

CPU part        : 0xc09

CPU revision    : 10
Hardware        : Freescale i.MX6 Quad/DualLite (Device Tree)

Revision        : 0000

Serial          : 0000000000000000

[Jeff Waller]

There are 2 things that appear to be direct result of this new OS/processor.

On startup:

WARNING: unable to determine host cpu name

And also, apparently julia sets the git crt path based on the OS, but in the case of this and others like it, the OS will not be recognized.

Fails:

julia> Pkg.update()

INFO: Updating METADATA...

WARNING: fetch: GitError(Code:ECERTIFICATE, Class:SSL, The SSL certificate is invalid)

But not if:

julia> LibGit2.set_ssl_cert_locations("/etc/ssl/certs/ca-certificates.crt")

0

Also, anything that requires JIT is slow.  So having everything pre-compiled if possible is desirable.

[Scott Jones]

What do you really need in Julia on the drone?

You might be interested in the branch of Julia I'm maintaining, in https://github.com/ScottPJones/julia/tree/spj/lite,

where I've attempted to cut out as much as possible from Base, while still having a useful version of Julia.

(I've been building it for my Raspberry Pi 2 (Model B)).

I've made it so that you should be able to select what parts you want included, simply by adding flags in Make.user.

It does save a substantial amount of memory / resources.

[Jeff Waller]

You know it's kind of a feeling right now + 1 specific thing and + planned thing.

The grand idea is. I want to imbue a drone with AI, which in general requires an implementation and a community and Julia is a good pick.  Latency is a possible problem.

Right now the hardware is not super fast but maybe not for long.  Not entirely new, but a better approach.

Currently, I'm using Kalman filters for a better GPS estimation, and in the future, maybe constrained optimization for determining the best location to navigate to best video angle.