1st spinning camera footage




Marcy 2's power plant is overpriced junk from Tower Hobbies.  They didn't send the $1.50 of Dean connectors ordered.

The Castle Creations 6 is really badly soldered.  The 12-30-4110kV Electrifly has incredibly flimsy wires.  It's obviously high flex cable & I should have left the bullet connectors on, but they looked heavier than they were & they easily broke off.





She does indeed fly.  Video points nearly sideways.

 The 1st images at flight RPM were pretty bad.  A refrigerator & chair are visible.

Instead of hitting head on, the camera scanned diagonally, causing sheering in addition to vertical compression.  At the highest shutter speed, it was still pretty blurry.  Each revolution has 6 frames, so forget about lining up a frame on the same spot.

The test harness was pretty unstable.  A stable attitude would give better results.



 Camera rotation improved matters.


Increasing the camera to 30fps, letting it drop 1/2 the frames, & letting it drop magnetometer samples got more overlap.  If there was a way to automatically align everything, this might work.  Slow scan 640x480 was useless.  The trend is towards lower resolution & higher clockspeed.

Next, we have 160x240 with every frame sent twice to reduce dropped frames & full magnetometer data.  A lion is clearly visible.


Finally, a shot in color 160x240 at 24fps, with 1/2 the frames dropped.  More detail is recognizable to a human, but probably not to a computer.

It's hardly the sharp daylight footage envisioned, but this is a matter of the size of the lens & the sensor quality, not available technology.

Ride on a monocopter

Since the camera is going to point diagonally, it's hard to envision a target it could use for navigation.

Trying to spin up Marcy 2 outside resulted in the wind taking her off & the mane immediately being attacked.  Untangling required destroying the propeller, since press-on propellers can't be removed.


At least it showed daylight improved the picture quality & a monocopter could be very useful for imaging outside.

 Automatic placement didn't go so well.


 Rotating manually matched a little better, but since the camera was pointing diagonally, it only needed 90 degrees of rotation.  If it pointed straight down, it would rotate 360 deg.
Playing with the Marcy 2 cam showed the realtime 360 deg panorama isn't going to happen.  There's no way to align all the frames fast enough & the information is too noisy to convert to an altitude & position.
Next comes shooting 1 frame per rotation at the highest framerate possible, so the 1 frame can be as close to the same position as possible & capture the highest resolution in the direction of rotation. 

There's no way to trigger the camera at any random time. The nearest frame jumps around a lot more as the framerate decreases.  The extra processing for color slows it down by nearly 1/2.
A slower framerate to increase the span of each frame by widening the line spacing was disastrous.  It really needs the tightest line spacing possible.
It can probably go higher than 42fps if only 1 frame per rotation is captured & the frame buffer is diabolically hacked.  40Mhz is the maximum that any home made solder traces ever did.  It's currently doing 42Mhz to get 42fps.
If there was any advantage to using a custom board instead of http://www.8devices.com/product/3/carambola/specs it was the ability to get very high framerates from the camera interface.  A USB webcam on the Carambola would be real slow. 

  The coning angle is a lot steeper than expected, making pointing straight down hard.

Now some useful commands for accessing Marcy 2 without compiling a wireless network driver on every computer.

iptables -t nat -A POSTROUTING -j MASQUERADE
echo "1" > /proc/sys/net/ipv4/ip_forward

on the computer with the network driver.

route add gw amazon

on the computer with the ground station.
That there is a board so badly designed, it's nothing but rework.  The mane shock was a TO-252 had the lowest current capacity of all the LM317 packages & this board uses a lot of current.  If money was infinite, a low dropout regulator would be used. 
After many experiments, it turned out the STM32F4 I2C core sux.  Software I2C solved the timeouts & it may be ignoring the ACK was the key to RF robustness.  Software also went a lot faster.  The hardware I2C may have added delays somewhere, to comply with the spec.

No matter how high the clockspeed, hardware I2C never could get over 64 samples/sec.  Software could do 120 samples/sec.  Video framerate had to drop & the DCT needed a lot of I2C polling between those raster lines.  10k pullup resistors were necessary.  The STM32F4 has 50k pullups.

  There's something you never thought would happen.  Full telemetry & video over wifi.  Depending on the video detail, it'll go up to 4 megabits.  It's not as much telemetry as a quad copter, but the 2.4Ghz bitrate is slightly higher.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Moderator


  • agreed . great work . especially for its model.


  • Jack, let me say that i admire you a lot, you really work to make things happen, you are like the few people in the world that "dreams and makes"

This reply was deleted.