[ home ] [ pony / townhall / rp / canterlot / rules ] [ arch ]

/townhall/ - Townhall

A place for civilized animals
Name
Email
Subject
Comment
File
Flags  
Embed
Password (For file deletion.)

[Return][Go to bottom]

 No.703

File: 1562500101526.jpeg (219.6 KB, 1152x712, 144:89, 971033.jpeg) ImgOps Google

Felt bored might delete later.

In general this is a thread about projects and stuff. Post about projects you're doing or have done in detail. Feel free to ask questions, critique or just blog about your own stuff. Usual rules apply.

This is more to I guess gauge how this kind of topic will go. I don't guarantee I'll complete my project in this thread.

 No.705

File: 1562503029376.png (2.83 MB, 2300x1450, 46:29, 1406169.png) ImgOps Google

So my next main idea for a personal project is to create a self-contained pose estimation unit. Just something that will stream out quaternions in NED (North,East,Down) on a serial port. I already have a 9-DOF INU and some microcontrollers. My intent is to dedicate a microcontroller to just this task, allowing this self-contained component to be used and reused in other projects.

My core requirements are simply:
>process gyro, accel and mag data into NED quaternions.
>stream it out on a serial port.
>target AVR (that's what I have with me atm)
>built using a standard linear algebra library.

Some nice to have features :
>calibrate over a separate interface.
>use a language better than C/C++
>stream out barometer data on a third interface
I actually like c/c++ but even with the features in newer versions it can be so unnecessarily tedious. The problem is there doesn't seem to be much I like better. There are plenty of languages I like better, but most are wholly inappropriate for embedded systems. Candidates so far are D, Nim and Rust.

D is mostly out, despite being my preferred for so many reasons, it has close to no support for AVR... It also has a garbage collector which I'd rather not deal with... I want to use D but I don't think I can.

Nim looks nice and compiles to C which can be easily be compiled to AVR. It's somewhat pythonic and can easily call external functions. This is important because I don't really want to rewrite a linear algebra library. The compiling to C thing is useful because it makes the language platform independent. There are other compilers in other languages that compile to intermediate languages.

Rust is the newest hot thing. Supposedly some people are looking at using it for embedded systems. Looking at the supported architectures though, AVR doesn't look well supported either. I'm lukewarm about rust anyway.

The hard part
Is actually mostly done. I already have a Unscented Kalman Filter that does all the sensor fusion written in python using numpy for the lin-alg. I wrote this some months ago and I think it works. I guarantee it will need some tweaking and bug fixes later though. But I can't build it for AVR. Python itself is a candidate I suppose but it would involve just as much messing around finding a compiler that will work and I'd probably have to rewrite the whole filter anyway since it probably uses features that require a full python interpreter. I also don't like the current interface so I might as well port the whole thing any way.

What I'm going to do from here
There are a lot of thoughts and design decisions I haven't even mentioned yet but I don't want this to be a book. I think I'm just going to start with porting it to C++ and investigate whether it's worth using armadillo as the lin-alg library over just CLAPACK. I think it's important to keep my ambitions in perspective and just make something that works before I worry about nice to haves and developing an embedded programming workflow that doesn't suck.

tl:dr I try to eat something that would never fit into my mouth, but I'm an idiot so I do it anyway.

 No.708

File: 1562508245156.png (274.24 KB, 1024x1024, 1:1, ddd.png) ImgOps Google

>>705
Let's back out a bit.  What's a pose estimation unit?  I take it it's a computer thing of some kind.

 No.724

>>708
Orientation estimation is probably a better description. So I want something that gives an unambiguous estimate for whether the sensor is pointing 'north east and slightly up' or 'west and slightly rolled' for example.

 No.725

>>724
So you're planning to use inertial navigation for that.  What scale of distances?

 No.726

>>725
Whatever scale I want really. It doesn't really matter over what distance it's used. Or rather I don't plan on correcting for anything like that.

I should say, that Sunday night was a poor choice for this thread. I doubt I'll make any further progress until next weekend.

 No.727

>>726
OK.  I know about C and C++.  Nim is new to me.  Hmm...  As you said it looks somewhat Pythonic, but seems to compile.  That could be nice, Python is slow.  I don't know -- so many languages, it seems sometimes.

 No.729

File: 1562584303388.png (734.53 KB, 1280x867, 1280:867, 960948.png) ImgOps Google

>>727
Python isn't necessarily slow. Or rather the answer is 'it depends' but is it more than capable of doing heavy lifting if you need it to.

Apparently there does exist a python interpreter for the AVR, but I don't see much point. I want to run on the bare metal here.

For what it's worth I got nim to compile for the avr and it works. Or at least the low level stuff is written in C and then bound in nim. The hex files produced is basically the same size as if I wrote and compiled the C myself.

This is fine though. What I'm looking for is syntactic sugar with a decent inheritance system without much overhead. I don't mind writing implementation classes in C++, so long as I can call those classes. perhaps nim can provide that.

I made a half hearted effort with rust too. but nothing really useful. It could be done for ARM arches but that's not what I want.

Next step is seeing if I can bind CLAPACK functions in nim... Or some other lin-alg library. Apart from normal matrix math I need to do cholesky decomposition for the UKF to work.

 No.730

File: 1562607301802.jpeg (640.83 KB, 1280x960, 4:3, fs_sslep.jpeg) ImgOps Google

>>729
>Python isn't necessarily slow. Or rather the answer is 'it depends'

You can correct me if I'm wrong, but when people say that I usually think they mean it isn't slow if using functions bound to a fast language like C or FORTRAN.

I don't know linear algebra.  Just the normal kind.  Seems to me you're doing more than basic dead reckoning.  Something more fancy.

 No.733

File: 1562626926356.png (43.14 KB, 1280x852, 320:213, 968881.png) ImgOps Google

>>730
I guess that's true. But it's surprisingly fast on its own and on the other hand the standard library can produce a lot of overhead. It doesn't really matter I guess.

Linear algebra is probably what you mean by the normal kind. Adding and subtracting matrices, solving systems of equations etc. Cholesky decomp can be though of as taking the square root of a matrix. It's used in the unscented transform.

Kalman filters are more complicated than dead reckoning and the unscented transform is another tool again for approximating non-linear transforms in a linear way. They are topics on their own that I'll write about later if you want.

 No.737

File: 1562717382316.jpeg (326.09 KB, 1000x824, 125:103, 1002436.jpeg) ImgOps Google

I think the upcoming LLVM release, 9, is adding official support for AVR. There's already a D compiler front end for LLVM. Maybe compiling D to AVR is possible. In 6 months time...

Anyway. Managed to find a port of Eigen and a small standard library for the avr. After some fiddling it builds without complaint. It will remain to be seen if it works.

 No.743

>>737
After more fiddling I've accepted this was a waste of time. I've got a lin-alg library now so I'm just going to use it as is. No more fucking about with bindings.

 No.744

File: 1562808712341.jpeg (172.52 KB, 566x517, 566:517, 2015240.jpeg) ImgOps Google

>>743
>No more fucking about with bindings.
Sounds like a project on its own.  I've only played with binding, never anything serious.

Occurs to me I've got an old phone or two where the screen is practically unusable.  I managed to get AirDroid on it, so I can remotely access the screen.  I've been trying to think of a use for them, if any.  Not sure I need pose estimation for anything, but it would have the hardware, I think.

I can talk about a project on my mind, but I have to get ready for work now, so maybe later.

 No.747

File: 1562837517988.png (865.26 KB, 1280x779, 1280:779, 962390.png) ImgOps Google

>>744
>Sounds like a project on its own.
Yeah. I guess I just wanted to see what options are out there. For what it's worth there seems to be a lot for support for ARM devices across numerous languages. I have an STM32F4 laying around too, but I don't want to use it for this project. I suspect that the community appetite for the AVR is low.

>I  can talk about a project on my mind, but I have to get ready for work now, so maybe later.
Sure.

 No.754

File: 1562894038065.png (18.46 KB, 104x186, 52:93, rk1.png) ImgOps Google

Working out and planning on cosplay for next year. Who knew that losing weight would make your previously measured clothing not fit. This genius.

Will either start over with my plan as Big Boss, or Joshua Graham.

 No.764

File: 1562979863351.png (934.67 KB, 1169x544, 1169:544, Screenshot from 2019-07-12….png) ImgOps Google

>>703
>ARM, AVR
All the languages I use run on my phone, although sometimes only in terminal mode.

I'm not sure if I'd call if a project proper, since I don't know whether I'll produce a result, but I've been playing with creating 3d models of trees, preferably based on a real tree as opposed to algorithmicly.  Photogrammetry can get the trunk, but beyond that the shape's complexity is too high.  I'd need to create some kind of leaf detector, then work that in with the photogrammetry pipeline.  Probably beyond my skill, but I'll play with it.

 No.771

File: 1563021804932.png (376.21 KB, 1000x810, 100:81, 959533.png) ImgOps Google

So started on the proper work. I hadn't talked about the hardware yet, so I figure now is the time. I'm using a Pololu IMU module which has a 3axis gyro module, a combined 3 axis compass and accelerometer module and a barometer module on the same I2C bus. It also has a regulator on it so I shouldn't be able to accidentally destroy it. I've collected all the datasheets and found some interesting application notes produced by ST giving some serving suggestions for each chip. This will hopefully save me some tedium of figuring out which registers have to do what.

At the moment I've just started writing driver classes for the modules. I'll work on the filter later. While looking for product specs, I looked at commercial products that do the same thing I'm doing except less shitty. Seems like most use Extended Kalman filters, but fuck that.

>>754
I don't know what a joshua graham is but costumes are cool. Is this a regular thing you do?

>>764
That's pretty neat. What algorithm are you using to get that far?

 No.774

File: 1563050958246.png (18.46 KB, 104x186, 52:93, rk1.png) ImgOps Google


 No.784

>>774
Fair enough. I'm sure you have a lot to do as it is.

 No.790

File: 1563106263763.jpeg (219.69 KB, 1280x688, 80:43, 1003916.jpeg) ImgOps Google

I wanted to progress further than I did this weekend. I ended up just writing the make file and writing the glue code, reading from the I2C bus, putting it into structs and writing out to a serial port. I should really use something with a build system rather than writing make files by hand.

I'll just make the excuse that I'm tired.

 No.801

>>703
>>771
>What algorithm are you using to get that far?
To be clear, this isn't my software, I'm just using it.  The algorithm is called scale-invariant feature transform (SIFT).  It finds correlated points based on textures.  Then with a bunch of, I'm guessing, linear algebra, the computer resolves the camera location and 3-space position of the correlated points from the images.

 No.803

>>801
I admit I don't know much about classifiers, but that's pretty cool. I'll read more about it later.


[]
[Return] [Go to top]
[ home ] [ pony / townhall / rp / canterlot / rules ] [ arch ]