Aliens Motion tracker with video, sound and RADAR

martinr1000 said:
Looks great, are you going to be able to blend the transparencies of the blips?
Click to expand...

Yeah that would be the plan. There is actually a black ring around them that makes it look worse than it is, but yeah, it needs work. The direction this particular code branch is going is kind of away from what the movie does, if you single frame step through the tracker scenes it is pretty interesting and I think I will go for at least two animations - one as close as I can get to the movie and at least one more that has my own flavor to it.
 
Great, hope you can sort it out. I didn't have enough knowledge to figure it out for Arduino so I used Pi, which has it's own problems such as slow boot time and size (pi zero is great but still tight in the body of the tracker). Hoping you can show me how it's done. Cheers
 
Here is the first full animation, pretty simple but I think it is acceptable and I would have been happy with this as a final result when I started. The color is wonky because the changing brightness is messing with the autoexposure on the camera and it is jerky because the shutter is not synced but this gives you an idea of what it looks like.

https://imgur.com/a/xXxp569

This is running right at 28 fps, you can spin the compass as fast as you want and it has no impact on the frame rate. In the clip it is just in a continuous 3 stage loop where the aliens get closer in each stage - hard to tell in the clip because it is in a loop. For now I "solved" the overlapping blip problem by just making sure the blips don't overlap, but there is an alpha blend function in the library I am using and I will see what that does. What you see in the movie is different, if I had to guess how they did it - it looks like they put drops of dirty water on glass and then shot it from underneath then it goes from overexposed at the start of the pulse to underexposed at the end of the pulse – just a guess. This project is far from done, I want to see if I can do an animation that is closer to the movie one, there is no sound yet, the tracker body is not done and I want to redo it anyway, etc, etc, etc… But at this point I am happy with the electronics, the Teensy 4 is a winner and has the power to do what I wanted so that is good.
 
Last edited:
Thanks for the enthusiasm, I do appreciate it. I do these projects because it is my hobby and I enjoy the challenge but it is also very nice when others appreciate the results and understand the effort that goes into doing something like this. As to the alpha stuff, hmm at first blush alpha blending does not seem like the right way to do this. My thought process on how to do anything is how can I do this with the least effort, cost, cpu cycles, etc. So the idea of: draw circle A with an area of pixels that are wrong, then draw circle B with the same amount of area of pixels that are wrong (we are now at 2x wrong area pixels drawn) then try to fix it by alpha blending (at least 3x but the math on alpha is kinda meh and it might be more than 3x) is not really appetizing to me. A seemingly simpler solution is just to never draw pixels from either circle into an overlap area defined by a chord between the two x,y coordinates where the circles intersect. It does get a little tricky when you have more than two circles that overlap but that’s what god created for loops and arrays for. I think I might give that one a shot first and see how much hair I end up losing because I did a quick benchmark on the overhead of some of the pixel pushing methods in the t3n library and it is kind of ugly looking. Don’t get me wrong, if you want to do this kind of stuff it is either a Teensy (or some other high mhz ARM) and the t3n library or you go to a PI, but calling those methods is not free and the overhead from calling them is substantial for alpha blending because you have to – for each pixel: read pixel – apply alpha – write pixel back and it is per-pixel and that means that my optimized custom methods to draw things like an annulus go from a single call to push 3 pixels to 9 calls and that is not great. Not all is lost on alpha, I won’t go into it now but I might have some tricks up my sleeve about how to play games with the frame buffer and use two of them by swapping pointers out from under the library after the DMA SPI transfer starts, but that is a whole other story.
 
Here is the “simplified chord” method, no alpha stuff:

https://imgur.com/a/E22sb46

I think that works ok. It was embarrassingly easy to fix the transparency issue. When things are getting complicated and every step you take to try to fix the problem makes it more complicated, it is time to take a step back and look at the big picture and think about what is happening and is there a better way to do it. The way I was doing it was two nested loops – an outer loop to iterate over all the aliens and choose the ones that would be at least partially on screen, and then an inner loop to draw each blip one by one – the gradient is done by drawing concentric filled circles on top of each other with the outermost being the darkest gray up through white at the center. It might seem like this could be a real performance problem but it turns out that it is not and is in fact the solution that has the best performance.

Draw 10,000 times with radius 30:
Circle outline: 144,769 microseconds for approx 190 pixels per draw x 10k
Filled circle: 370,464 microseconds for approx 2,800 pixels per draw x 10k

The above numbers are not at all what you might expect – it takes about 2.5x as long to draw 2800 pixels as it does 190 pixels. The reason why is because circle just pushes single pixels to draw the circle outline and filled circle calls drawfastVline and does not draw each pixel – it draws fast lines that don’t take nearly as long as if you tried to draw a line pixel by pixel by calling the drawpixel method over and over again.

So what was the solution? Just swap the loops around and instead of fully drawing each blip individually - draw just whatever layer of the gradient we happen to be on for every blip on each pass. There might seem to be to performance gains to be had by intervening in the draw process and preventing overlapping draws but that does not work and makes for worse performance.

I am probably going to need a different method to draw the more screen accurate stuff, still thinking about how to do it.
 
Last edited:
I love everything about this. I messed with one of those microwave radars years ago as part of a car alarm project. It is freaky how they pick up on people moving, and you can dial in the distance. Unfortunately they don't work as well if they are actually moving because of the doppler effect they use.
 
The "Radar" is the weakest part of this project. With all the automotive radar stuff out there hopefully some day soon there will be small cheap modules that will output speed/distance/heading info for multiple targets in realtime. Random thought: Perhaps I should have a big blip occasionally show up for the Queen alien....
 
So I just realized how a real handheld tracker might work in theory. Heck it maybe how car radar works: You need a 3D radar sensor, something that can triangulate the direction of a return signal. If your sensor happens to be moving, everything around you would have a predictable doppler return, based on the angle relative to sensor vector. Any return from a external moving object would have a different frequency of return, relative to the background.
 
just a thought, i've heard that some blind people use echo location devices that allow them to navigate pretty well, no idea how available or expensive the tech is but seems like a good fit for a device like this
 
Awesome work so far. I have a real part motion tracker and would love something like this for it. Any plans on making them to sell?
 
I am not selling these, it is my hobby and as soon as money is involved it stops being fun and starts being work. I would be glad to give advice and ideas to anyone who wants to make their own.
 
Just a quick update, so it does all work now - getting data from the mpu and using it to spin the compass and playing sounds in a non-blocking way and I met my FPS target of 25+hz. I am still working on the sound samples and the more screen accurate display version so there is plenty left to do not to mention the tracker body rework stuff that I have not really started on yet. A few thoughts about the Teensy 4. The good: Performance, it gets an A+ on that one, the bad: a little rough around the edges as far as software support goes. The T4 is very new and it is kind of to be expected that you are on your own if you stray from the base Teensy 4 libraries. One of the areas that turned out to be an issue was audio. Teensys have a niche in audio in that they have always concentrated on that area and they have their own audio shield that by all accounts works very well and has good software support on the T3 and T4. I could not use that solution because it was just too large to fit in the tracker and so I had to go my own direction with the MCP4725 DAC and the issue with that is that there is just no library to use that DAC in the way that I wanted to use it. I knew the 4725 hardware could do what I wanted from reading the datasheet for it but all the libraries and info about that DAC on “Arduio” were, shall we say lacking, in a big way and so I had to write my own low level code inside an ISR to interface with it. Not a big deal for me but I can see how someone less experienced with this stuff might just be stuck at that point and have no way to move forward short of a total reboot of their project. If you need the raw power of the T4 – then get it but know that with great power comes great..whatever. If you need more than a 16mhz AVR, there are plenty of ARM micros out there for you to choose from including the T3 and in many cases I think the T4 might not be the best choice, it just depends on your situation and skill level and what you are willing and able to do if you end up in no-mans-land on the T4.
 
multiplexor said:
Just a quick update, so it does all work now - getting data from the mpu and using it to spin the compass and playing sounds in a non-blocking way and I met my FPS target of 25+hz. I am still working on the sound samples and the more screen accurate display version so there is plenty left to do not to mention the tracker body rework stuff that I have not really started on yet. A few thoughts about the Teensy 4. The good: Performance, it gets an A+ on that one, the bad: a little rough around the edges as far as software support goes. The T4 is very new and it is kind of to be expected that you are on your own if you stray from the base Teensy 4 libraries. One of the areas that turned out to be an issue was audio. Teensys have a niche in audio in that they have always concentrated on that area and they have their own audio shield that by all accounts works very well and has good software support on the T3 and T4. I could not use that solution because it was just too large to fit in the tracker and so I had to go my own direction with the MCP4725 DAC and the issue with that is that there is just no library to use that DAC in the way that I wanted to use it. I knew the 4725 hardware could do what I wanted from reading the datasheet for it but all the libraries and info about that DAC on “Arduio” were, shall we say lacking, in a big way and so I had to write my own low level code inside an ISR to interface with it. Not a big deal for me but I can see how someone less experienced with this stuff might just be stuck at that point and have no way to move forward short of a total reboot of their project. If you need the raw power of the T4 – then get it but know that with great power comes great..whatever. If you need more than a 16mhz AVR, there are plenty of ARM micros out there for you to choose from including the T3 and in many cases I think the T4 might not be the best choice, it just depends on your situation and skill level and what you are willing and able to do if you end up in no-mans-land on the T4.
Click to expand...

if you're interested I have sound samples in my project you can use. They are in my github repository.

github.com

AliensMotionTracker/resources at master · martinr1000/AliensMotionTracker

an aliens inspired motion tracker application written in python for raspberry pi inputs - martinr1000/AliensMotionTracker
github.com github.com
 
Could anyone following this thread point me in the direction of a vendor selling spare parts for Aliens Motion Tracker kits? Really only need one particular part, wouldn't even care if it's 3D printed... I attached a picture.
 

Attachments

  • part.jpg
    part.jpg
    119.3 KB · Views: 120
Hi there has anyone got the tracker link below working ? because i need a it of help.
www.therpf.com

raspberry pi aliens motion tracker

Hi all, I've been working for a long time now to create a viable motion tracker prop for the raspberry pi. I'm happy enough with my results to share that with you now https://www.youtube.com/watch?v=UzfXKLisqew&t=67s The good news is that if you fancy making one I'm sharing the source code...
www.therpf.com www.therpf.com
 
spacelordess said:
Could anyone following this thread point me in the direction of a vendor selling spare parts for Aliens Motion Tracker kits? Really only need one particular part, wouldn't even care if it's 3D printed... I attached a picture.
Click to expand...
So you only need the top part of the kango drill. Do you have the rest of the drill`s lower section.
 
You must log in or register to reply here.

Similar threads

renato3xl
Aliens working motion tracker Mod
Replies
1
Views
1,336
joberg
joberg
Mannie Bothans
Noob Needs Electronics Advice (Sound and LEDs) Please Help
Replies
17
Views
1,805
Oracle
Oracle
propmainiac
Aliens Motion tracker build
Replies
16
Views
4,034
darthsideous
darthsideous
OneSpaceman
Alien Powerloader Motorcycle.
Replies
1
Views
1,004
Astyanax
Astyanax
paulsboutique
Aliens M314 Motion Tracker - Yes, another one or two with CAD and 3d printing
2 3 4
Replies
65
Views
9,870
joberg
joberg
Back
Top