Marcy 2 finally does the 1st step in flight: stabilized rotation on the ground, using the onboard camera & blob detection. Making the RPM slow enough for maximum efficiency makes it too unstable to take off without active control.
It took only 1 week for the super simple ESC to arrive from Hobbyking. The way to deal with them is to break up an order into segments small enough to ship in 1 week. Instead of 10 motors on the 4 week shipping plan, create 10 orders on the 1 week shipping plan.
It could be passively stable, with landing gear, higher RPM, & more weight.
For now, the lighting is provided by 150W CFL's.
Next is the hard part: detecting position from the onboard camera in flight. Exactly how to test it is the hard part. Coning angle & RPM change depending on altitude & payload.
The mighty flood fill algorithm from 1980's PC Paint makes another appearance in Marcy 2's blob detection algorithm. It's normally instantaneous with a 160x240 image, but here it has to flood fill hundreds of blob candidates in each image, then take the largest blob. That's very slow. After much optimization, 25fps of 160x240 takes 10% of a 3.8Ghz processor.
The Marcy 2 algorithm separates a marker from a background with changing viewing angle & lots of noise. Here it's shown separating markers from a lion. The camera is configured to only capture hue & saturation, to reduce the JPEG compression load on the microcontroller.
There was a blob tracking demo in OpenCV, with undoubtedly the same algorithm, somewhere. The demo only seemed to show a difference algorithm with a static background. There wasn't any documentation for any other blob tracker, & 10MB is a bit large for a blob tracking library.
There is a camshift algorithm in OpenCV which might do a better job. The algorithms have usually not been precise or reliable enough to fly something. There's a big change going from a Willow Garage robot which takes 30 seconds to move an arm to an unstable aircraft which needs precise, reliable data 4 times a second to avoid crashing. You also have to be under 25 to use OpenCV.
So the mighty USB problem of 3 months was narrowed down to a toggle error, meaning a packet was dropped. No surprise, since it was always the 1st 64 bytes of an 802.11 frame that were missing.
The improvement after keeping the bus busy was because the packets were all multiples of 64 bytes, not the bandwidth.
The breakthrough was noticing the errors only came after packets which were even multiples of 64 bytes. A hack to only flip the toggle bit after packets of odd multiples of 64 bytes fixed the great stm32f407 URB_ERROR problem.
It was a single line in USB_OTG_USBH_handle_hc_n_In_ISR:
if(((pdev->host.XferCnt[num] + 64) / 64) % 2)
pdev->host.hc[num].toggle_in ^= 1;
Ping then became 100% successful, manely limited by RF glitches. No lockups anywhere, no URB errors, & the promise of full wifi with the microcontroller was finally realized until the next microcontroller comes out.
While simultaneous send & receive still isn't possible, it's not necessary for any of Marcy 2's requirements.
That was a lot of work & a waste of time. The Wifi settings could have been changed with a much faster ground station protocol. There's no desire to implement packet spanning in the http protocol. There's just enough space in a single packet to handle all the configuration pages.
The USB limitations make it impossible to time out while waiting for an ACK, so TCP over wireless is really clunky & doesn't promote a lot of confidence in putting $100 of parts in the air. The UDP protocol for flight control is bulletproof, but psychological impressions come from TCP.
It's yet another interface to worry about. The web server only came up because it's the 1st place people think of for configuring the wifi parameters.
DNS & TCP need to be hidden features, enabled by a buried option in the ground station. A jumper across 2 pins will be required for resetting to factory defaults. A key for you web based wifi configuration coders: disable the motor until reboot.
The Marcy 2 router package is as complete as can be. Up to 8 stations are supported. They can't do anything besides ping, flight control, & the web based configuration.
You should be aware that EVERYONE is in a race to build the 1st personal flying droid. The winner will happen when the 1st personal position system that actually works appears, setting all 500 of you UAV entrepreneurs off on 30 endless nights promoting your kickstarter accounts, ordering your sparkfun parts, & getting the thing working.
The leading candidates are now based on vision. The radio, sonar, GPS, & lidar contenders all have problems. 1 thing you may not have thought of is for a personal droid, flying within 10ft of the user, battery power isn't always required.
If it's hovering near someone exercising or shooting video of a talking head in a defined space, it can be tethered. Tethering gives an element of infinite loitering time that your inductive charging stations can't match.
Quad rotors still seem too expensive to penetrate the mass market. Those 12x30mm brushless motors are never going to be produced in enough quantities to meet demand while those 7x16.5mm brushed motors don't last long enough.