Building speed measurement hardware

[LinusLarsson]

I was having a brain storming session yesterday on how to do timed runs fairly accurate with something I can bulid myself, on the cheap with not too much of a time investment. First, I have no idea how the speed guys do their measuring so I am starting from blank head here.

There where a lot of ideas in my head but this is the one that finally stood on top. Requirement was that it should be simple to build and operate by myself, be at least "fairly" accurate. Cheap! Ability to study the times after flight and perhaps real time measurements. I have scrapped real time for now, it could possibly be done in the future using image analyzing. But it's not that important.

Using two cameras pointed 90 degrees from the field with clocks synced. This will in the first version not give you the velocity on the fly, but instead you analyze them afterwards. Syncing the clocks could be done using normal NTP to I think within 1ms, another idea to try is to let the base computer send out pulses to sync. The sync is of course used to know EXACTLY when a frame was taken in the video. I believe this can give an accuracy at least within 3kmh or so on a 100M stretch. This could be used to time anything that flies, no transponder or anything needed which is a plus.

There are some problems that needs further investigation. I need to get the frame number from the h264 feed on the PI in real time and tag it with the clock or syncsignal from base station. I do feel I want to do this every frame and not just at the beginning of the feed. A dropped frame could spell disaster otherwise... But it's solvable.. Also, web cameras may have internal buffers, and the frame it send might be old. I think by using identical hardware this should not be a problem. I'm also not sure it's easy to see the exact frame the helicopter crosses the line.. Hard to say, need to try.

I have a picture explaining what I need to build. There are two video computers using raspberry PI and one base station. Ethernet between them for now, WIFI could possibly be done. After I have made some runs I have a session at the base station to find the heliplane/whatever passing by the cameras. The blue line is imaginary at the field but will be visible on the screen. The flags are setup once using whatever means I have to get a straight box, then I can leave them at the field for fast setup next time. I believe some known length string and Mr. Pythagoras can help me get a true straight box.

I don't know if I'm going to build this, I want some inputs. Please rip it to pieces if it's a shity idea, I can take it. Or come up with completely other ideas if some other mean of measuring is feasible and buildable. I believe the cost would be sub 300$.

[LinusLarsson]

Having done some testing I am pretty sure I can just shoot low res still images (perhaps 160x480, don't need much horizontal res) in a fast rate (minumum is considered to be 30), sending them realtime over the network to the base station. Tested on a regular computer, no problem. Too bad I couldn't find my SD->microSD converter so no testing on the PI as of yet.

This will build up space fast on the base station hard drive, but really no problem for a 5 minute run. And very easy to tag the images with exact time code without having to read the h264 spec.

[Vinger]

We have a manual timed system over 5.8GHz signal and the 100m to each timing point does influence a lag over the radio link, so one has to allow for it in the software. I am no expert with software, but the guy that did the program for us did measure it and wrote a correction into the timing profile.

[LinusLarsson]

Yes, lag is a big part of the problem. I will have the time localy at the camera stations to minimize this. The images need to be time tagged as soon as they are fetched from the camera.

[Ace Dude]

The question you need to ask yourself is how accurate is accurate enough?

RF links are always going to have variable delays so you'll never be able to have a perfect delay factor built in. While some delay factor is better than none, it's still always going to vary from run to run. Also using a non-RTOS is also going to have some inherit variation.

Bottom line is time to develop, cost, and complexity are going to go up with increased accuracy. At some point you need to determine how much accuracy is enough.

[LinusLarsson]

Originally Posted by Ace Dude

At some point you need to determine how much accuracy is enough.

Well, I wouldn't do this unless I thought some accuracy was fairly easy to achieve. I'm going for a shutter speed of 30fps on the cameras which should be achievable. I'm shooting for an accuracy of 30ms over the course which is good enough for me. However I think better accuracy is achievable using some tricks...

But really, it's too early to tell.

[LinusLarsson]

I did som prelimenary testing on raspberry pi hardware and found a video mode that outputs 640x480@90fps! So I'm back to video... Did some testing of hooking in right after the video encoder so I can know exactly where in the file I am at a certain time.. I belive this gives me sub 20ms accuracy.

[Ace Dude]

Any error you have on one side will need to be doubled for the other side.

165mph = 242ft/s

At 90fps that's a picture every 2.69ft if my math is correct.

You'll also need an accurate way to measure elapsed time.

For personal use, any accuracy is probably good enough. For competition it's a bit more complicated.

The past two years at IRCHA there was a camera system in place. It was brought over from German and used very expensive high speed cameras.

[LinusLarsson]

Originally Posted by Ace Dude

Any error you have on one side will need to be doubled for the other side.

165mph = 242ft/s

At 90fps that's a picture every 2.69ft if my math is correct.

You'll also need an accurate way to measure elapsed time.

For personal use, any accuracy is probably good enough. For competition it's a bit more complicated.

The past two years at IRCHA there was a camera system in place. It was brought over from German and used very expensive high speed cameras.

Of course, I'm very happy if I can get within a couple of kmh for a run. This is on the cheap after all. When using it you have to learn to run straight passes for good speed. It will be a very nice training tool.

[Ace Dude]

Exactly. For self practice, good enough is good enough. Heck, if it were me I probably wouldn't even worry about timing and just focus on technique. With good technique will come improved speed.

[LinusLarsson]

I'm not even competing... I have no desire to. However we have a lot of things that fly fast at our club, and things that run not so fast but can still be meassured. I'm also up for a hacking challenge and this is a nice project.

I've have done some grunt work. Added an option to the standard video recorder in raspberry to output the timing data I need. The rest can be done in a higher level (easier) language so it's actually already coming together. The camera stations needs a server that accepts commands for staring/stoping video. I'm going to try some Python...

[Vinger]

I'll be first in line to get a nice R2 Prototyping off the shelf system running on a Raspberry system........

[LinusLarsson]

Got a simple HTTP server going with commands for starting stoping and quering the status of the video feed. So now it's time for the base station. Hopefully I can figure out how to jump aroundin a h264 video...

[LinusLarsson]

I have made another milestone, the data from the camera stations are one h264 file and a file with timing data. The timing data is a file consisting of timestamps with milliseconds and fileposition when it comes in from the hardware encoder on the raspberry. These will be sent over the network realtime to the base station.

Now, the base station decodes the h264 and knows the fileposition when a frame is decoded, from that it encodes a bunch of jpeg images (one for each frame). Using the file position from the decoder, and looking up the file position in the file from the camera station I can get a very reliable timestamp.

The decoding, and jpeg encoding is done. And I know the timestamp on each jpeg, remember I'm going at 90 fps so even if I'm off by a frame it's still very good data. The important thing is that all showstoppers which could spell problems are done now, I think.

My Core I7 laptop can decode h264 and encode jpeg in 9 times realtime. It doesn't neccesarily have to be realtime, but it's nice it's fast.

[LinusLarsson]

I have done some serious testing by filming a phone with a timer app on. I'm not going to jump the gun and say this works, but it's looking good for further pursuing.

With further pursuing I mean it looks in the range that it's justifiable to dump the money on another raspberry with camera setup. I really need to film from two cameras to get a definitive answer of the accuracy.

[Vinger]

Great news, you and Tom really innovative......

[LinusLarsson]

I am so hoping this works out. I am already dreaming about organizing a friendly competition (and yesterday I said I had no desire to compete, things changes fast). Me (R5) and Goblin speeds in one class (I don't think we have any other speed helicopters in Sweden). Normal helicopters in another class.

It's for fun and doesn't have to be dramatically serious (or to the kmh accurate), not at this stage. Getting people together and have some flies and a laugh is more important than the actual results.

If this winter could stop I could actually maiden the R5 also...

[LinusLarsson]

Update, I started all over!

I digged more into the camera API of the rasperry and I am now outputing uncompressed YUV data from the camera instead of a H264 video stream. What this means is I get the data truly frame by frame (and get a timestamp on the frame as soon as get it).

This is a lot of data, every frame is 230kb so I can't of course save this to disk reliably. so what I do is to send the frames into a jpeg encoder on the fly and save the jpegs. The raspberry can't do this on one core, but it has four so I went multithreading for the encoding and saving of the images. Now I save the images over NFS (network) to a RAM drive on a Linux computer. It's extremely fast.

So my first program is scrapped, and a new one is in! It's a way better program, less steps to go through.

And now to the important part, accuracy!

I am seing jitter times from the camera of as max 9ms. What this mean is that I know a jpeg is captured somewhere within 9ms. This is extremely good and better than I had hoped for.

Doing the math on this taking some other variables into account I think I can have an accuracy of 1% if you run 250kmh over a 100M stretch. 0.5% over 200M. This is in my opininion nothing short of spectacular for this kind of cheap hardware...

What I like about this new program is it feeds you directly a bunch of jpegs with timestamps on. There is very little "programmer black magic" going on here, which means it's easy to explain exactly what the program do.

[Vinger]

[LinusLarsson]

Thank you Vinger.

I am still using Rasperry PI 2 hardware, Pi 3 is faster and could possibly show even better times...