[julia-users] Re: julia on ARM for a drone

[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.

[julia-users] Re: julia on ARM for a drone

[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.

On Sunday, February 7, 2016 at 1:50:55 AM UTC-5, Jeff Waller wrote:
>
> 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.
>
>

[julia-users] Re: julia on ARM for a drone

[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.

[julia-users] Re: julia on ARM for a drone

[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: 

Serial  : 

[julia-users] Re: julia on ARM for a drone

[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

On Sunday, February 7, 2016 at 12:20:55 PM UTC+5:30, Jeff Waller wrote:
>
> 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.
>
>

[julia-users] Re: julia on ARM for a drone

[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.