The newer iPhones have this "slo-mo" mode, which is basically very fast video (240fps) that you can then tag a certain section to have it played back slowly.
On recent trips I managed to capture some interesting footage, for example: some seagulls that flock around the ferry in Helsinki harbour, on the way to Suomenlinna Island:
Or leaping dolphins at the National Aquarium in Baltimore: (note that we had been going here everyday for almost a week, which is why I got relatively good at anticipating when they do neat tricks. What I enjoyed about this aquarium is that they don't just make the dolphins do crowd-pleaser tricks, but take time to explain the kind of interactions and trainings they do to keep them healthy. Keeping marine mammals in captivity is a controversial subject...
Kinda cheesy, but pretty neat for the first while at least...
Ever since the intern Canadian UAV regulations were released, I've been wanting to put together a relatively cheap, but HD Camera carrying drone that is light enough to be exempt from any regulation. At the threshold of 250 grams, it was actually quite doable at a relatively low price given the extremely rapid developments in the DIY quadcopter industry over the past few years.
This is the second, but much more used iteration of the particular frame. The first had a 4 in 1 ESC and F4 controller which I blew up on a hard crash (did not disarm when it dove into the ground in acro mode), and due to parts I had available it was rebuilt using slightly less optimal (weight-wise) parts but ended up flying very well, so I kept it even after replacement parts arrived.
Before delving into the details, here's a google photos-created video from some footage I took while travelling in Finland for a conference. The small size of the quad means I can carry it easily in a backpack containing my work laptop (13" MBP) without adding too much extra weight.
Here's the finished build "in action" next to the transmitter, out on the field on Aalto University campus:
Parts list and build details
Frame: Realacc RX130 that came with a Matek PDB. (Used to be able to find it for about $13-15 on Aliexpress)
Motors: ReadyToSky 1306, 3100kV (available only on AliExpress from what I can find; example link. They are super cheap clones of the DYS 1306 at half the price, but the latter are much better in quality. Supposedly 4s capable but I've only ran them on 3s so far. Works fine!
ESCs: EMax 12A "BlHeli" which actually had to be manually programmed with "real" BlHeli. They're not super light but can be found for cheaper from eBay and AliExpress merchants. However, I would actually rebuild it with a BS412 (25x25mm) or maybe a RacerStar 4in1 (30.5x30.5mm). The latter is 20A and would work with 1407 motors which could support a larger craft (160mm frame swinging 4" props). A 4in1 (even larger 20A one) would also be considerably lighter than the 12A EMax's I'm using. For discrete ESCs the EMax Bullet series may be better as they're much smaller and lighter.
FC: I'm using a strange Piko BLX clone board that has a curious 23mm!? hole spacing. It fits in between the standoffs of the 30.5mm spaced stack, but is not ideal. I would probably just go with a full size 30.5mm FC for this frame next time... or else go 20x20.
Receiver: FlySky A8S. Tiny, supports failsafe fine despite product description stating otherwise, and no reliability issues that seem to be a problem with older versions that are no longer sold on BG...
Batteries: ZOP power 3s 500mAh 45C. They're not rated for consistency, and of the two I have one seem to work better than the other. Having said that both allow me to zoom around for about 3 minutes or so lugging the HD camera, or do more aggressive manoeuvres without the camera.
Props: DYS 3045. The only 3" props I've used so far. Seems to be a good match and they're pretty, so not too much to write about at this point... ;)
Camera: the trusty RunCam 2 HD. Weighing in at 50 grams with battery and SD card, its not the lightest option but its a nice action camera to boot. I could have shaved about 15 grams off by not using the battery and powering it off the 5V rail of the PDB instead. Another interesting option would be the new Split that weighs about 20 grams or so and has a faster analog signal for realtime FPV feed (requiring an analog transmitter of course), but the Split is pretty much a dedicated flight camera and can't be used elsewhere by itself.
Transmitter: The trusty FlySky i6 which I modded to 10ch, and the i6ab receiver is still working well on the 250 class quad.
The build weighs in at exactly 250 grams with the camera, which is about 15 grams more than when I had the BS412 4in1 ESC and F4 controller with built in 5V regulator which eliminated the need for a PDB. This means I don't have room for a lipo voltage checker/alarm (such as this one), and I have to go by gut feeling and go by experience from more open locations when I didn't need to conform to regulation.
Previously, with the lighter 4in1 ESC:
Here's some raw, unedited zooming-around-the-park footage:
All in all, a very fun quad that gets a lot more action than the 250 (5") one due to the size and legal status. The Canadian regulations have recently been updated to be a lot more reasonable, but anything that weighs over 250 grams (and less than 1kg) is still relatively restrictive in terms of space.
I fiddled for a good part of the day trying to find a low-latency local network video streaming solution to implement a "FPV"-like control for the robot using a RPi camera module. It turns out a bunch of existing solutions (like VLC streaming etc) have really high latencies. This is OK for things like a security camera, but not so much for realtime control.
Finally, this rather hacky solution using netcat appeared to work best:
1. On the client (viewer/controller, running on a Mac) side, run:
netcat is used to listen and send; raspivid grabs the video and pipes it to netcat, and on the other side netcat pipes the received data and spits it into mplayer.
This was the only way I could get less than 1s of latency on the video feed, although it still wasn't great. Having a good USB wifi dongle also helped a bit. Finally, changing the dimensions of the video using raspivid actually made it much slower, probably due to software resizing of each frame on the fly compared to just sending out the raw feed from the camera.
Next steps: get some more interesting sensor info from the PiShield, and get a separate power source since there seem to be random system freezes when the motor and Pi are both running off the same power bank.
UPDATE Oct 26:
with the advice of a very helpful redditor who suggested gstreamer, I gave it a shot this evening.
On Raspbian, gstreamer1.0 is currently already in the official repos, so no need to add custom sources as these earlier instructions.
For OSX, I just downloaded and installed the latest compiled version from the official source. It also handily tells you that by default the path for the commands are at
/Library/Frameworks/GStreamer.framework/Commands/
From here, we can either have a tcpserver on the Pi that a client can connect to, in which case:
Mac (note explict path to gst-launch-1.0 command, since I haven't added it to path):
/Library/Frameworks/GStreamer.framework/Commands/gst-launch-1.0 -v tcpclientsrc host=IP_OF_RPi port=5000 ! gdpdepay ! rtph264depay ! avdec_h264 ! videoconvert ! osxvideosink sync=false
Now UDP would be faster, and in this case it would be similar to the netcat example where the RPi would define the UDP "sink" using the IP address and PORT of the viewer (on the Mac), which would yield the following:
RPi (note destination should be explicitly defined by the source this time):
Eye-balling the two versions, I feel like the UDP version is slightly snappier, but considering that my network is not very congested, I have a feeling the difference wouldn't be as much as if I had a lot of traffic running. Regardless, this is a HUGE improvement over the existing solution! Should try to do some timing tests to see if I could get a better measure of the actual latency - perhaps using a photo of a stopwatch like this guy did (which was one of many sources I originally consulted for the netcat solution above as well)! finally, here's a test on the actual video latency of the setup above: looks like its somewhere between 150 and 200 ms.
FINAL UPDATE (Jan 2017)
Yet another option, is to use RPiCamWebInterface. In the end I didn't get around to do the latency measurement, but it feels *almost* as fast as the previous solution. The other bonus is the client user interface is far nicer!
Here's a sample video showing the stream in action:
