better FPV multicopter design

[FrankBuss]

The current DIY and most commercial RTF FPV copters are all the same: there is a camera with an analog PAL or NTSC output, an extra camera signal sender, usually at 5.8 GHz, a 2.4 GHz receiver which outputs servo signals, a controller board where you connect the (analog) servo signals, and the controller board controls individual ESC boards for each motor, which drive the brushless motors. And then multiple batteries (or one battery and some extra BECs) to provide the voltages for the different modules. The advantage of these setups: it is flexible and you can combine modules from many different manufactures. But I think there are some disadvantages.

First the ESC could be integrated to the main control board. This would allow easier update of the algorithms of the ESC, lower latency and better logging possibilities (motor stall, current etc.).

Then the receiver could be integrated and changed to use digital signals. This would make it more flexible. No more a limited number of channels and loss of accuracy because of the PWM modulation (needs a new sender, too). Would it be possible to use WLAN? How much is the latency?

And then the camera could be connected to the main controller board, with a digital interface (like the industry standard CSI interface, for which you can get powerful cheap cameras). If the controller board uses an FPGA (the required power for the FPGA would be only a fraction compared to the motors), the FPGA could even do some real-time image process, e.g. for obstacle avoidance or speed calculation.

With a high resolution CSI camera, the FPGA could create a MP4 stream to log it to a SD-card as well. No need anymore for an extra action-cam. For the video downlink, the FPGA could scale the image to reduce the bandwidth. Easiest solution then would be to convert it to PAL or NTSC to use existing sender and receiver hardware. How much is the video latency from a CSI camera? If it first buffers one image, it could be already too slow for some FPV experts

But the video feed could be sent digitally, too. I think a line based transmission would be even better than the analog system. With analog video transmissions, sometimes multiple frames are lost, until the receiver re-synchronizes. With sufficient synchronization information in the digital signal, only a few lines should getting lost. Would it be fast enough to use WLAN for this, too? Using 2.4 GHz has the advantage that the signal has less problems with reflections or shielding by trees etc. than 5.8 GHz and you could use an off-the-shelf WLAN transceiver. Of course, because the camera downlink is digital, it could contain telemetry data, that are not visually embedded in the video feed, so that the video receiver can decide what to do with it, or how to log or process it.

This system would be not as flexible as the traditional system, but would result in a much better copter, if built for one specific model.

And regarding the PID tuning: why has this to be done manually? I'm not an expert, but IIRC there are algorithms which do this automatically. If it starts with some reasonable default values, and then measures lots of data, including GPS, accelerometer, gyro and maybe even evaluate the video feed (could be done offline on a PC), this shouldn't be too difficult.

[Kilrah]

First the ESC could be integrated to the main control board. This would allow easier update of the algorithms of the ESC, lower latency and better logging possibilities (motor stall, current etc.).

But then when one fails you've got to trash an FC and 3 working ESCs, and you lose in placement flexibility. Fast control, logging and updates in no way require physical integration, all of these are actually already implemented.

Then the receiver could be integrated and changed to use digital signals. This would make it more flexible. No more a limited number of channels and loss of accuracy because of the PWM modulation (needs a new sender, too).

Already the case. Again integration is not desired since it would limit physical placement options, restrict compatibility and brings nothing extra.

With a high resolution CSI camera, the FPGA could create a MP4 stream to log it to a SD-card as well. No need anymore for an extra action-cam. For the video downlink, the FPGA could scale the image to reduce the bandwidth. Easiest solution then would be to convert it to PAL or NTSC to use existing sender and receiver hardware. How much is the video latency from a CSI camera? If it first buffers one image, it could be already too slow for some FPV experts
[...]
the video feed could be sent digitally, too. Would it be possible to use WLAN? How much is the latency?

All of that already exists but stays constrained to consumer-level toys because even if it's been around for a few years now and there's been quite a bit of development around it performance is still an order of magnitude too low for anything half serious. See this for an example.

This system would be not as flexible as the traditional system, but would result in a much better copter, if built for one specific model.

The current market thrives only because of the modularity and the ability to mix and match, and to replace individual components. Most FPV flyers enjoy the building side, and getting good results with something they put together themselves plays for a lot (if not most) of the reward they get. Most would also not be able to afford replacing a $400 all-in one board that integrates everything from camera processing, transmission, FC, ESCs etc when just one of those functions fail (or the board gets physically broken, which is the main reason for things failing, and would be much more likely with an integrated board due to larger size and/or less robust construction coming from the integration) instead of changing a $10 ESC when it's dead.

And regarding the PID tuning: why has this to be done manually? I'm not an expert, but IIRC there are algorithms which do this automatically. If it starts with some reasonable default values, and then measures lots of data, including GPS, accelerometer, gyro and maybe even evaluate the video feed (could be done offline on a PC), this shouldn't be too difficult.

Several systems already have autotune facilities, they do a pretty good job (better than someone untrained would do manually), but at the top level people still get better results with manual tuning.

Fully digital systems are great for some purposes e.g. imagery and recent DJI machines are perfect examples of current state of the art in the field, and the perfect incarnation of what you suggest. But their use on machines intended for the "fun of FPV flight" and racing purposes depends on significant technology improvements in other fields that will need a few more years. There are several attempts at making it work that have been going on for years, yet nothing truly usable has come out of any of them yet.

Actually a lot of the technology that would enable it already exists... but given its only current applications are in very specific professional markets it's ridiculously expensive and completely out of range.

[hendorog]

Good ideas.
The top bit of your post is about increased integration of the components.
I watched a friend fly his DJI Phantom 4, those are very integrated and actually not far from what you describe. It was certainly much slicker than what it was like only 2 or 3 years ago when everything was DIY.

Regarding the PID loop, what you are describing is called PID auto-tune. In industrial controllers you can just wire it up and hit the autotune button.

The controller disturbs the process with a step change in setpoint and then they would observe the response and calculate PID values. I once used on on a Vinegar fermentation process which was allowed to be too cold or too hot. It was a nervy couple of hours watching the controller ramp up the temp not knowing when it was going to turn around and start cooling.

So this would need to be done with a multi-rotor safely tethered somehow - so it didn't hurt anyone or anything and didn't destroy itself either.
It could be also be done with fixed wing in flight if the controller had a failsafe ability to switch back to manual control and was done with a bit of altitude to recover. That could be a bit hairy though and too hard for the inexperienced person who just got a new toy

Regarding digital video, this has been done before. I think the DJI Phantom 4 might be digital - it is HD anyway. The challenge as you noted is to keep the latency down compared to analog. All the cool kids fly low and fast these days in organised races etc and so latency matters. Also in that multi-flyer environment bandwidth matters too.

[FrankBuss]

First the ESC could be integrated to the main control board. This would allow easier update of the algorithms of the ESC, lower latency and better logging possibilities (motor stall, current etc.).

But then when one fails you've got to trash an FC and 3 working ESCs, and you lose in placement flexibility. Fast control, logging and updates in no way require physical integration, all of these are actually already implemented.

Do you have an example where this is already implemented? I know only the usual ESCs, which have power-in, gnd, PWM-in and 3 outputs. There is no current measurement, or any other measurement you could do, like a scope of the back-EMF for tuning.

Then the receiver could be integrated and changed to use digital signals. This would make it more flexible. No more a limited number of channels and loss of accuracy because of the PWM modulation (needs a new sender, too).

Already the case. Again integration is not desired since it would limit physical placement options, restrict compatibility and brings nothing extra.

Do you mean the S-BUS? It is very limited with the fixed 25 bytes format. You are right about compatibility problems, but with a new powerful standard protocol, there is no need for an extra board and hard-wired connection to the controller board. With an integrated receiver (maybe SDR based), it could even be programmed for any protocol you like, to make it backward compatible. Looks like everyone is using Naze32 anyway, so no need to make this modular to be able to replace the controller board independently of the receiver.

If the placement is important, or if it is better to swap the controller board without the additional cost of the receiver, then a better bus should be used, like CAN. This could be used to connect external ESCs, too, which would allow to replace them individually, or connect 6 or 8 for if you have more motors. And with a CAN-bus you could return information from the ESCs.

You are right, placement of the ESCs might be important, because I guess the power driver should be as near as possible to the motors when it PWM-switches the motors with 30A or more. But then this could be just the output stage and the controller board could have 6 outputs for the FETs and some inputs for the back-EMF and current measurement for each motor (with a FPGA there are enough IOs). This would combine both: the flexibility to do anything on the controller board and the ease of replacing a broken driver board, or using different driver boards which can handle more current.

Placement of the receiver should be no problem, it has an external antenna anyway.

With a high resolution CSI camera, the FPGA could create a MP4 stream to log it to a SD-card as well. No need anymore for an extra action-cam. For the video downlink, the FPGA could scale the image to reduce the bandwidth. Easiest solution then would be to convert it to PAL or NTSC to use existing sender and receiver hardware. How much is the video latency from a CSI camera? If it first buffers one image, it could be already too slow for some FPV experts
[...]
the video feed could be sent digitally, too. Would it be possible to use WLAN? How much is the latency?

All of that already exists but stays constrained to consumer-level toys because even if it's been around for a few years now and there's been quite a bit of development around it performance is still an order of magnitude too low for anything half serious. See this for an example.

The Bebop 2 looks nice, but the latency is more than an second (a bit faster for the Phantom, but still too slow) :



That's unusable for FPV. I guess a big part of the latency is because of the iOS or Android operating systems and displays. And WLAN might be slow, too.

You are right, the board would be bigger, but in sum less expensive than a full modular solution. And it shouldn't break, because it would be still very small and usually it is mounted with damping or standoffs because of the accelerometers and gyros. Put this in a nice case like the CC3D Atom and then there is no way that the board breaks.

[Kilrah]

Do you have an example where this is already implemented? I know only the usual ESCs, which have power-in, gnd, PWM-in and 3 outputs. There is no current measurement, or any other measurement you could do, like a scope of the back-EMF for tuning.

Extreme high-speed PWM for control, one-wire for configuration. I had already mentioned those in another response to you...
For the control side CAN would be a huge step back as it would be a lot slower than the current solution. The overhead is enormous.

There have been ESCs with current measurements but in the racing world small size is considered more important. If we do a measurement it's over total consumption. Motor response is tuned "offline".

Do you mean the S-BUS? It is very limited with the fixed 25 bytes format.

It does the job, there is no need for more.

Looks like everyone is using Naze32 anyway, so no need to make this modular to be able to replace the controller board independently of the receiver.

You're very mistaken, the Naze is actually pretty much obsolete now, the "high end" market is made of at least a dozen boards that may or may not share some things from it. Also already mentioned.

You are right about compatibility problems, but with a new powerful standard protocol, there is no need for an extra board and hard-wired connection to the controller board.

Some people have Futaba radios, some have Spektrum ones, some use FrSky, some use any of these but use an UHF RF system isntead of the built-in 2.4GHz one... they want to be able to use what they have, be able to choose, and not have to buy something specific or be locked into anything - expecially as again, there would be no practical gain.

The Bebop 2 looks nice, but the latency is more than an second (a bit faster for the Phantom, but still too slow)

That's precisely why WLAN is not an option, and the proof that with current commonly available technology the best that can be achieved within reasonable prices is unsuitable.
The system on the Phantom is the best you get with relatively expensive custom solutions.

You can look up the Connex Prosight for a digital video solution that trades off range and quality for latency, it's state of the art for that version of the compromise, just became available in small quantities but it's still considered too slow by the race pilots, in addition to being way too expensive and bigger/heavier than what people want to load their machines with.
So...

And it shouldn't break, because it would be still very small and usually it is mounted with damping or standoffs because of the accelerometers and gyros. Put this in a nice case like the CC3D Atom

What you describe would not fit in a CC3D Atom case, it would be the size of 2 or 3 large mobile phones.

Everything is relevant and will probably happen, but there's a large number of hurdles to jump until it's even possible, and it would have to be significantly better than existing systems on each and every point to have a chance on the market. Horizon would be 5-10 years IMO.

[Marco]

There's two problem problem with digital video, the communication is often far too polite and good encoding software isn't available. Both are obviously solvable.

First of do data transmission with AMICCOM or Nordic modules and only stop transmitting if the RSSI is high enough that you can't shout over it (with a tracking antenna this will rarely be the case). It's silly to get squeamish about this if the alternative is using an analog transmitter which throws much more power into the air and doesn't care about others either.

Then you need to make a protocol for H.264 transmission which can gracefully deal with packetloss, the link is low latency ... so up to a point you should re-request lost packets. When you run out of time and you need to accept some lost packets the encoder needs to know, so it can use intra-coding for the lost blocks instead of the error propagating for a while. x264 has a sort of scanline scrolling intra mode as far as I recall, which would already improve a lot on standard coding. Still not ideal though, it doesn't make the best use of the fact that there is a bidirectional data link.

[FrankBuss]

Kilrah, this BLHeliSuite ESC config program looks neat. But I think it would be still good if the current can be measured and logged while flying, maybe even for each of the 3 motor coils. This would allow to detect problems with the bearing or the props early before it breaks. It doesn't need many parts, just a small current shunt (maybe could be  even a trace on the board) and an opamp. If the ESC uses a microcontroller, it should have enough ADCs.

The fast CAN bus standard allows 1 mega baud transfer rate. Overhead is not that high: for up to 8 bytes data it is 5.5 bytes overhead (addressing ID etc. included). Say you have 8 motors connected to the CAN bus, each requiring 2 bytes to control it, it would be 60 bytes, so it could update the ESCs with 16 kHz. The ESCs I know are running with 450 Hz and I don't think it makes much sense to go higher than 1 kHz. Plenty of time left for the receiver and other components to connect to the same bus. But maybe overkill, because it needs CAN bus driver and receiver chips, protocol handlers in the microcontrollers etc. I think the solution with one big FPGA and only dumb FET drivers (and current measure) near the motors would be the best solution. The FPGA could be reconfigured for different copers, say if you have only 4 motors, you can use the other IOs for other things. Of course, as a DIY kit this would be for engineers and not for Joe Average who doesn't know much about electronics or what a FPGA is.

Regarding the S-BUS: For me it looks like a quick hack which kind of works, but it is not nice. What if you need more than 11 bit resolution for a channel? And it has only 2 digital channel bits. Things like switching the flight mode would need already these bits, and then you don't have any bit left for enabling a lost-beeper (I know that the remote controls are sending the 3 position digital switch with one channel and different PWM signals for the different positions, so the S-BUS does this probably, too, but this is a bad hack and a waste of bandwidth). And if you could specify the frame format, a lower latency would be possible, because you might want only 4 channels with 12 bits instead of 16 channels with 11 bits.

I didn't know that there are so many different RF systems. Thought it was all the same, just more or less PWM encoded channels. But it doesn't need to be backward compatible, if it is much better than the existing systems Found an article about the existing systems here. Quote for the 2.4 GHz band: "Each manufacturer of Txs design and use their own unique protocols for frequency hopping within the band."  Why couldn't they just use all the same protocol, like WLAN, but faster? But I think the same FPGA on the controller board which controls the morots, with some SDR hardware, could decode them all (at least for one frequency band), if you want backward compatibility. But might be not as sensitive as a dedicated analog receiver frontend, and more expensive.

[FrankBuss]

There's two problem problem with digital video, the communication is often far too polite and good encoding software isn't available. Both are obviously solvable.

First of do data transmission with AMICCOM or Nordic modules and only stop transmitting if the RSSI is high enough that you can't shout over it (with a tracking antenna this will rarely be the case). It's silly to get squeamish about this if the alternative is using an analog transmitter which throws much more power into the air and doesn't care about others either.

What are the range of these modules? I know the Nordic modules can implement different protocols. Maybe this would allow to implement a faster protocol than WLAN or Bluetooth, if it is too slow.

Then you need to make a protocol for H.264 transmission which can gracefully deal with packetloss, the link is low latency ... so up to a point you should re-request lost packets. When you run out of time and you need to accept some lost packets the encoder needs to know, so it can use intra-coding for the lost blocks instead of the error propagating for a while. x264 has a sort of scanline scrolling intra mode as far as I recall, which would already improve a lot on standard coding. Still not ideal though, it doesn't make the best use of the fact that there is a bidirectional data link.

Re-request lost packets should be avoided. Using a line-by-line encoding for image transfers, with a fixed bandwidth, would be better, because then you can just blank the broken lines on the receiver side. Re-request and using H264 would add more latency, because you might need to buffer at least one frame.

But using such a Nordic module would be nice, if the bandwidth is sufficient for video. The other direction could be used for the remote control signals. Lost packets are not important for this direction either, because it sends only constant positions for the servos.

[Marco]

What are the range of these modules?

AMICCON claims 200m with PA/LNA ... they also claim slightly higher sensitivity than Nordic. Tracking antenna would help. You could also use more than 1 if you needed more bandwidth.

Re-request lost packets should be avoided. Using a line-by-line encoding for image transfers, with a fixed bandwidth, would be better, because then you can just blank the broken lines on the receiver side.

If you want to use motion compensation (and you do) then errors will propagate for quite a bit. As long as you have control you have uplink, you should make good use of that, bi-directional video links will always be able to deal much better with packet loss than uni-directional.

Re-request and using H264 would add more latency

Adding say 50 msec of window for retransmission isn't going to matter much for the user experience. H.264 doesn't inherently add latency, that entirely depends on how you use it ... you can in theory do motion estimation on the fly as you read out the image sensor, you don't have to buffer even a single frame. Even if you do intra-only coding you'd still want to use H.264 over M-JPEG.

[Kilrah]

The fast CAN bus standard allows 1 mega baud transfer rate. Overhead is not that high: for up to 8 bytes data it is 5.5 bytes overhead (addressing ID etc. included). Say you have 8 motors connected to the CAN bus, each requiring 2 bytes to control it, it would be 60 bytes, so it could update the ESCs with 16 kHz. The ESCs I know are running with 450 Hz and I don't think it makes much sense to go higher than 1 kHz.

Current flight controllers run up to 8kHz, and current FC->ESC interfaces support going up to about 40kHz. Again I had already pointed that to you so if you don't know of ESCs faster than 450Hz you're really making an effort to ignore the current state of the things.

Regarding the S-BUS: For me it looks like a quick hack which kind of works, but it is not nice.

It's a solution to a need, and it fulflls it well.

What if you need more than 11 bit resolution for a channel?

You don't. Nobody has >11bit resolution fingers.

And it has only 2 digital channel bits. Things like switching the flight mode would need already these bits, and then you don't have any bit left for enabling a lost-beeper

Those 2 bits are a relic of when Futaba created the first 8-channel digital transmission about 20 years ago. It was a neat way to get 2 more channels for things that were strictly on/off. It made its way into SBUS becasue why not, guess they had 2 free bits... but nobody ever uses them, they're kinda pointless since the 16 proportional channels are enough for basically everything.
Switching flight modes, controlling a lost beeper is done with those. Anything more advanced is done using the telemetry / communication interface while the SBUS interface is dedicated to realtime control.

But it doesn't need to be backward compatible, if it is much better than the existing systems

That's the point, so far none of the above points neither solve a problem nor provide meaningful improvements, and thus wouldn't make people change their gear that works perfectly well.

"Each manufacturer of Txs design and use their own unique protocols for frequency hopping within the band."  Why couldn't they just use all the same protocol

Obvious commercial reasons. You buy a radio and keep it for 5-10 years, no manufactuer could last if they couldn't sell accessories. That and the "system" aspect (a radio and all its accessories and features) is what makes a commercial difference.

Adding say 50 msec of window for retransmission isn't going to matter much for the user experience.

It does. If you want to make a successful system you'll need less than 100ms TOTAL from capture to display, not much margin to just throw 50 more here or there.

[FrankBuss]

Adding say 50 msec of window for retransmission isn't going to matter much for the user experience. H.264 doesn't inherently add latency, that entirely depends on how you use it ... you can in theory do motion estimation on the fly as you read out the image sensor, you don't have to buffer even a single frame. Even if you do intra-only coding you'd still want to use H.264 over M-JPEG.

Analog FPV systems have 20 ms latency, says this article, which also demonstrates their own digital FPV system with 50 ms latency (glass-to-glass). Might be too slow for the hardcore FPV racers, but I guess usable for most users. So there is already a closed source solution for this. Looks interesting, but I can't find a "buy" link.

Are you sure motion estimation could be done on the fly without losing a frame? And what happens, if it fails, do you see then the same frame displayed twice etc.? I guess this would be very bad for FPV racing. A fixed image-by-image transfer rate might be better, and then maybe with 100 Hz framerate so that latency is not that much, even if you buffer one frame.

[FrankBuss]

Current flight controllers run up to 8kHz, and current FC->ESC interfaces support going up to about 40kHz. Again I had already pointed that to you so if you don't know of ESCs faster than 450Hz you're really making an effort to ignore the current state of the things.

Sorry, I'm new to the hobby and I only know CC3D and Naze32 so far, and LibrePilot, which I think allows 450 Hz max for the ESC update rate, but looks like these are entry level flight controllers. Do you have some names of better ones? I guess if the control loop could run with 8 kHz, too, this would result in a much smoother flight.

You don't. Nobody has >11bit resolution fingers.

True, but could be a general purpose transmission protocol, like USB HID, which then can be used for sending back telemetry data as well, and then 11 bits are not enough for some measurements.

[Kilrah]

Do you have some names of better ones? I guess if the control loop could run with 8 kHz, too, this would result in a much smoother flight.

https://www.google.ch/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=f3%20flight%20controller

True, but could be a general purpose transmission protocol, like USB HID, which then can be used for sending back telemetry data as well, and then 11 bits are not enough for some measurements.

Again you don't use the same interface for that. Already exists, already works, no problem.

[FrankBuss]

Do you have some names of better ones? I guess if the control loop could run with 8 kHz, too, this would result in a much smoother flight.

https://www.google.ch/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=f3%20flight%20controller

Well, first link is "seriously pro", but I can't find the max ESC update rate. The manual on the webpage says "default 400 Hz" with the Cleanflight software. I thought you would know some controller names which can runs a 8 kHz control loop and can control ESCs that fast, too, so that I don't need to search myself Ok, found this page: https://oscarliang.com/best-looptime-flight-controller/ Looks like you want to use One-Shot for the ESCs and if you are using a flight controller with a STM32F3, a looptime of 8 kHz is possible and the ESC then are updated with the same speed. Would be nevertheless fun to implement this all integrated in one FPGA and leverage the lower latency, faster looptime and better integration (e.g. no quality loss because of conversion of the ESC control signal to PWM and then maybe back to digital on the ESC).

PS: there is already a nice project, which uses CAN (to be precise, UAVCAN, a version of CAN for aerospace and robotics) to control a ESC: https://pixhawk.org/modules/pixhawk_esc

[Marco]

Analog FPV systems have 20 ms latency

Theoretically. If the image sensor is rolling shutter, if the PAL converter and the ADC/deinterlacer work scanline by scanline, and finally the LCD controller doesn't pre-buffer a frame.

Are you sure motion estimation could be done on the fly without losing a frame?

Of course, just think it through.

And what happens, if it fails, do you see then the same frame displayed twice etc.?

You will very rarely lose an entire frame. As for what you do then, that depends, if you can make a good guess at motion vectors then you just do MC and forget about it.

[Marco]

I wonder what FPV Blue is using for the communication link at 900 MHz ... maybe they are using a normal WLAN IC and mixing it up/down?

[FreddyVictor]

Sorry, I'm new to the hobby and I only know CC3D and Naze32 so far, and LibrePilot, which I think allows 450 Hz max for the ESC update rate, but looks like these are entry level flight controllers. Do you have some names of better ones? I guess if the control loop could run with 8 kHz, too, this would result in a much smoother flight.

I wouldn't get too hung up on these 'impressive speeds'
The std rc pulse is 2ms (1ms pre + 1ms signal) long so theoretical max for a std signal is 500Hz
but then you can use short pulses to achieve faster speed
But I've seen better flight stability with controllers running much slower - the motors can only react so fast to changes

Current flight controllers run up to 8kHz, and current FC->ESC interfaces support going up to about 40kHz

I do know they run ESC motor pwm @ those frequencies, but would be surprised if this was for the actual interface tho' 

<edit>just to add:
an interesting take on a modular setup is TBS Gemini - see page 8 of manual showing pluggable ESC's and uC

[Kilrah]

I do know they run ESC motor pwm @ those frequencies, but would be surprised if this was for the actual interface tho' 

Yup, current microcontrollers have fast timers, instead of having them count up for an eternity to generate  a 1-2ms pulse the same principle is kept but which a much shorter pulse, there are several standards but the fastest one is a range of 5-25us instead. Of course the limit is the mechanical part in the end, but a faster loop always helps with more accurate predictions. And yes at some point those crazy speeds are also quite a bit more of a marketing thing than a real benefit.

[onesploit]

About "loop-times" few cents of own thoughts:

• If your gyro is max 8kHz raw samples, that is unprocessed without any filtering step yet, if you sample the same thing over and over from the statistical point of view what's the benefit of it ? Isn't it just stupidly eating more CPU cycles for the sake of having "faster loop times" ? No offence, but that's fact. One could use analog gyro with more samples, but there are no such designs afaik.
• What many people don't understand that PID is a closed loop system that not only consists of communication between ESC and FC, but also motors and how fast they can change their speed. There is no further improvement in PIDs from 4khz, 8kHz, 16kHz, 32kHz loop times.

Of course you can find people who will argue that there is benefit, and soon designs with optical fiber between ESC and FC or even better gyro on each ESC will emerge in this faster loop time race, but why who knows... There is really no benefit of that. Biggest benefit was gained form syncing to gyro, but further speed improvements are of negligible benefit. Especially that if you are off with your battery optimal PIDs would change more, than what you would gain from "better" tunning with faster loop. To me it's mostly populist marketing and I see no reason of runnign 16kHz or 32kHz, just stupid IMO.

[Kilrah]

The ultimate limits of usefulness are the sensor bandwidth and motor response time.

Reading sensors fast allows for more efficient / flexible filtering, oversampling is a common technique to extract more useful data. Whether current code is making use of it is another story though.
FC->ESC communication speed does have an advantage up to a point even if the motor response is significantly slower because the ESC runs its own RPM control PID. If 2 successive orders are very different there will still be less excusrsion from the desired value if they come closer to each other, of course up to a certain point.

But yes the whole thing is obviously mostly a marketing thing... but a powerful one.

[StillTrying]

How are you going to reduce the video latency? Even with analogue PAL transmission the camera and the LCD screen are each about 1 frame behind, = 40 to 80mS.

Here's the latest video transmission system with less than 10uS latency. 

[Marco]

How are you going to reduce the video latency? Even with analogue PAL transmission the camera and the LCD screen are each about 1 frame behind, = 40 to 80mS.

You can deinterlace to the field rate instead of the framerate.

Fully analog camera doesn't reduce latency relative to a rolling shutter digitized sensor BTW. They both integrate over 1/fps time and output immediately after. A CRT with it's HSYNC dynamically locked to the incoming scanlines could reduce latency relative to a "normal" LCD screen though, even if the LCD is also dynamically clocked and changing pixels with basically no delay. Because the CRT is stroboscopic and a "normal" LCD screen is sample and hold. Still because of the integration in the image sensor the delay is limited to a minimum average of 1/(2*fps) (depending on your definition of delay) which is generally more than 10 us.

FPV Blue seems pretty much on the bleeding edge of RF sensitivity, encoding quality and latency ... if the price is right there will be little to improve.