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.
The evolution of optical targets continues.
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.
In other news, there have been some ideas of going back to ground based vision for Marcy 2 & having a higher quality airborne camera just for viewing. Blob detection might be good enough to get ground based vision to work in ambient light.
The ground based camera is smaller than the ground based target & the payload is lighter. 2 cameras on the aircraft for navigation & aerial images are unlikely because of the CPU load. It would take another chip to serialize the data from 1 camera.
There's no way to envision 2 cameras with a single chip, but the ground based vision takes a lot more money. The ground based camera needs the 2 servos & a lot more fabrication than the target & both options need a takeoff stand.
Aerial vision is having real problems with inconsistent light. Takeoff happens on the ground, so the ground is covered in a shadow. There are taller takeoff rods. LEDs don't do white. They either make everything blue or red. Only CFL lights produce a real white which can differentiate between red & blue.
There's always requiring the user to fly in a well lit area & lighting the takeoff area with red LEDs. Most interiors are very dim. People keep their windows closed & use 60W lights, especially single people.
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.
URB_ERROR resolved
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.
Comments
Maybe I'm kicking in the darkness, but could you use IMU sensors outputs for the low-level stabilization as with multicopters or would the gyro be saturated?
Seriously, though - since I will likely be using the same library from ST - is that a line of code I can search for in their library, or did you add it?
I expect a full study of all the different methods of calculating multiples of 64, including bit masks, octal notation, lookup tables, & neural networks. While you do this, I'll be working on the position sensing problem.
Damn! I don't qualify to use OpenCV either...
Kudos on your USB debugging, and cool to see someone using the STM32 F400's - I am interested in those also, but minor bone to pick with your description of the issue and your code-
You talk about packet sizes of even and odd multiples of 64 bytes, but what your code really looks at is if the packet size falls within an even or odd 64-byte segment. Probably that's really what you intend, but it reads as if you want to check for sizes of ONLY zero or 64 or 128 or 192, etc.
Assuming that is the case, I would do this:
if (count % 128 < 64)
rather than what you have:
if (((count + 64) / 64) % 2 != 0)
since checking for even 64's is the same as checking for 128's