Do we need USB on STM32 autopilots moving forward?

[Philip Rowse]

Hi All
    I know this sounds like a strange question... we need USB for the following reasons....

1. Firmware uploads... how else could we do this so fast?
2. downloading logs....
   
3. changing parameters etc when on the ground...

All of these things are important... but we have an issue... we have 2M of Flash in our STM32F427 based systems... but we can only use 1M

we now have the capability to use CAN esc's and GPS's etc.... programmable LED's (thanks Solo) all of which have bootloaders that can be reprogrammed with images stored in Flash....

So... Solutions.

Rev 3 Hardware... but it is basically impossible to get.

or, rethink USB.  

here are a couple Ideas that have been suggested by various people.

1. Get rid of USB, and use a serial bootloader at 1Mb 
2. Move the log downloading to be run by the bootloader.
3. Find a common source of supply for all the manufacturers of F427 to be able to bulk buy the rev 3...

Keep in mind, that changing new autopilots to rev 3 does not help the 100's of thousands of existing units out in the market today.

I would love to see some more suggestions here.... keep in mind, we NEVER use USB in flight...

[Tom Pittenger]

I'm in favor of removing USB support:

1. Firmware uploads... how else could we do this so fast?
2. downloading logs....
   
3. changing parameters etc when on the ground...

1) there's a serial boot loader in the works. If there was demand for wireless bootloading then serial is the way to go. There are some concerns about it not handling lossy data streams but serial to TCP or BlueTooth may be an obvious workaround in the short term. Current 433/900 MHz is currently not reliable enough but in that pull request there is discussion about improving that later.

2) this is horribly slow, even for USB. This needs to be completely re-thought but I don't have any solutions.

3) Power over USB on the bench is a big plus, we should at least keep that. However, it will cause confusion regarding having USB but not being able to use it. Not the end of the world to lose this feature though as long as wireless somehow becomes a requirement.

Any thoughts on bumping the cpu up a notch to expand RAM and Flash? Now that we are running multiple EKFn instances RAM is a huge limitation and that will only get worse. The STM32F7 would offer 320kB (from 256kB) bump in RAM but it is relatively new and doesn't have any high Flash options yet: max is only 1MB. Something to keep an eye on.

-TomP

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Randy Mackay]

 

     For issue #1, I think the firmware upload will work reliably even if it’s over 1MB but the board will then randomly freeze or reboot if the user then tries to configure the board using USB.  So people would need to basically never use the USB except for firmware uploads.

 

     For getting the logs we could:

·         5.8Ghz Wifi<->serial adapter although it’s still going to be a lot slower than USB.  Maybe we could try to improve the GCSs / vehicle code so that syncing of logs happens more automatically?  Maybe if people kept the vehicle powered (perhaps even using a USB connector) the board would remain reliable and so the background sync (via wifi) wouldn’t be too annoying for the user?

·         A serial data logger with its own usb connection?  So you plug it into the board’s serial port, we then stream the log data to it in flight, then the user can pull it off that datalogger using the logger’s USB port (maybe it also has wifi).

 

     I like the #3 idea, a groupgets (https://groupgets.com/) would surely work with so many different manufacturers needing the chips but the logistics would be very time consuming especially the first time.

 

-Randy

--

[Andrew Tridgell]

Hi Philip,

The errata recommends using the OTG_HS peripheral in full-speed mode
instead of the OTG_FS peripheral.

Could we wire up the OTG_FS peripheral and teach NuttX to use that?

Cheers, Tridge

[Philip Rowse]

I am 100% in favour of bumping the Pixhawk 2 to the F7.... I have already modified one to do this, and David Sidrane has it already.

If this worked, then we gain memory, and speed... This is a good potential problem solver for the future, but it would be good to also help those building current generation boards, like Nick and Pixhawk 1 boards.

If the F7 replacement works, it's a simple mod, that I am happy to do... But

The Black magic probe is yet to support it...

NUTTX is yet to support it...

There are different clocks etc... 

Could be other effects...

@David Sidrane, can you chime in here with an understatement of what the risks are?

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER 

    3D Robotics

    +61 (0)427 326 366

    website | facebook | Instagram

[Tom Pittenger]

Not to get off topic too much, but even though we get more RAM and MIPS, the flash is limited to 1MB which puts us at our current artificial limit that we are approaching. Doesn't seem like a good long term decision with the current F7 offerings.

Meanwhile, we should probably refer to that be design as something other than PH2 since that is already in production with SOLO and that won't be changing.

PH3?

--

[Philip Rowse]

Good point.... :( 

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER 

    3D Robotics

    +61 (0)427 326 366

    website | facebook | Instagram

[Philip Rowse]

I was also looking at the STM32F479 which gives 120K more Ram as well as the 2M, not sure if it has the same Errata...

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER 

    3D Robotics

    +61 (0)427 326 366

    website | facebook | Instagram

On 7 Nov 2015, at 16:32, Tom Pittenger <t...@airphrame.com> wrote:

[Nikolay Arsov]

Yes, 429 has the same errata.
What about my old idea of ESP8266 ( simple cheap 802.11bgn ) as a USB replacement?
It uses just one of the serial lines.

[Philip]

Yes

That is a nice idea... We should get a few users testing it... See what the feeling is.

Phil 

--

[john...@gmail.com]

Please, please when doing the major upgrade to v2 hardware, select the biggest baddest chip you can fit on there.
The type of resource problems we have on the PX1 are frankly ridiculous for an ARM based system.

ARM chip's cost nothing compared to dev man hours.

[Luis Vale Gonçalves]

Philip,

couldn't the new possibility of having custom made RaspberryPi's (I believe there's a minimum quantity required) http://www.element14.com/community/docs/DOC-76955 be one of the solutions?

[Holger Steinhaus]

As a fix for existing Pixhawk, an option to abandon USB would be very useful, IMHO. I think the main purpose of USB is currently an easy and reliable fallback to restore communication with a potentially misconfigured Pixhawk. I did never ever use USB for log transfer in the era of 100MB-sized logs - I would take forever transfering them that way.

Regarding firmware updates: what about SD-card based upgrade (like any cheap digicam does)?

Holger

[Robert Lefebvre]

I can't remember the last time I fetched logs any other way than simply removing the uSD card, and sticking it in my computer.  It's fast and easy.  

I understand some people have the flight controller buried in a frame somewhere.  But maybe a two-pronged approach would work.  We promote people simply pulling the uSD if they can, (maybe we could offer a remote uSD board?) and if they can't then they'll have to use an optional extra interface board of some sort. (several have been proposed here)

Also, how is Nick Arsov getting the Rev3?

[Nikolay Arsov]

Hi guys,
By default, the simplest way is the serial communication - a cheap FTDI via any of the serial ports available - the console one for example.
The future way is the direct 802.11 via something like the cheapest device ever - ESP8266.
The first is a wire, while the second is wireless....to me, wireless is the future. More, the ESP8266 can be connected to the USART2 ( telemetry port ) without serious problems.

Robert, I got the Rev3 from Mouser - two successive deliveries ....it seems the Rev3 is in stock.

BR
Nick

[Craig Elder]

A minor consideration but one not too loose sight of is that we we currently use the USB connection to detect that we are on the ground and to disable the low battery alarm.  We'll need a replacement detection method if we do not have the USB connection.

--

[Tom Pittenger]

Craig, for plane we have an is_flying flag that I added a while back.

[Philip Rowse]

Glad to know people can get Rev3 :) , But considering the hundreds of thousands of existing systems out there, it would still be nice to find a solution for existing users.

Is flying would be good for making the battery alarm be quiet... But what if they try and relaunch when its triggered but quiet?

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER 

    3D Robotics

    +61 (0)427 326 366

    website | facebook | Instagram

--

[Tom Pittenger]

"Is flying would be good for making the battery alarm be quiet... But what if they try and relaunch when its triggered but quiet?"

Great topic for a new thread/issue.

[Evan Slatyer]

How about a cheap USB-to-CAN converter board that can be added onto existing systems? Three big advantages:

(1) Solves the USB problem for future boards, and hopefully it'd be cheap enough for existing users to add it to their systems easily (after all, it'd just be a cheap STM32 chip with CAN + USB, plus a CAN transceiver, plus a voltage regulator. Probably under $10 worth of components per board).

(2) You can have your USB port anywhere; doesn't have to be close to the Pixhawk. CAN lines will hopefully be running to external sensors already (airspeed, GPS, external compass, etc), which allows for locating the new USB port externally without running any new wires.

(3) Great for testing/debugging; being able to plug a USB cable into the vehicle while it's fully assembled and immediately see all the data (or update firmwares) on the CAN bus would be pretty handy. You can even do that without the Pixhawk itself connected. Or, if you land with a major system failure, plugging USB in through the USB-to-CAN board would avoid any disruption to the system so you could see exactly what's going through the sensors.

It's not good for transferring logs (because CAN is even slower than USB 1.1), but for firmware updates and parameter settings it should be fine. For transferring logs, I'm not sure that there actually is a solution with the existing hardware - the existing Pixhawk and PX4 don't have any high-bandwidth long-distance interfaces easily available. For the next version you could stick a USB2.0 HS PHY on there (or, for that matter, a 10/100Mbps ethernet PHY) but that's a pretty major change.




As a bonus, it'd be interesting to add an I2C and UART port to the board too (since both are essentially free to implement), which opens up the option of using the board as an I2C/UART-to-CAN converter. It seems like that'd be a useful product anyway, allowing people to convert old I2C sensors to CAN and also preventing a single dodgy I2C sensor from taking down the whole I2C bus (at worst it'd take down the I2C side of one converter, and if there's one problematic sensor you can put that on its very own I2C bus).




For what it's worth, I've actually got a board designed just* for this purpose, using an STM32F072. I've even got a first set of ten boards manufactured (bare PCBs, unpopulated). However, I've largely moved away from working on UAVs for now, so I've done nothing at all on the software side. If any of the APM developers want some boards to play with, I'm happy to send over the schematics and PCB design (KiCAD), and the existing PCBs for people in Australia (they will need to be cut out from the other boards in the panel).

(*) Actually the board was designed to power a dual-antenna ARM version of the 3DR radio, so it's got a 10-pin board-to-board header that would connect to the SI4463 radio module over SPI. However, it's also got CAN/USB/SPI/UART connections, which are what's needed for this project.


P.S. I have actually flown a plane with USB connected in flight. It had an external computer with "real" UARTs (ie the +/-12V kind), so connecting those to the PX4 would have taken extra hardware. Plugging in a USB cable was the easiest option at the time, and it worked fine for the few flights that occurred before we switched to the UARTs.

[Paul Riseborough]

I would be happy to forgo USB for anything other than bench power and firmware uploads provided there was a way to get logs off where physical access to the SD card is difficult and it would appear that a simple SD card extension cable can solve that issue.

USB is getting too slow for my logs anyway, so its only one vehicle I have now (an Iris+) where I still rely on the usb to get logs off.

On Saturday, November 7, 2015 at 12:15:29 PM UTC+11, Philip Rowse wrote:

[Philip Rowse]

http://www.ebay.com.au/itm/like/261836296286?limghlpsr=true&hlpht=true&ul_noapp=true&hlpv=2&chn=ps&lpid=107&ops=true&viphx=1

should do the trick

[Tom Pittenger]

I'm soooooo ordering one

On Nov 8, 2015 4:09 PM, "Philip Rowse" <phi...@3drobotics.com> wrote:

http://www.ebay.com.au/itm/like/261836296286?limghlpsr=true&hlpht=true&ul_noapp=true&hlpv=2&chn=ps&lpid=107&ops=true&viphx=1

should do the trick

--

[Nikolay Arsov]

Hi Tom,
Just have in mind that is a hinge, but not a push-push socket. I think you won't like it.

[Robert Lefebvre]

I would only want to be sure that the system will still function well if the SD card was disconnected in flight.

[Andrew Tridgell]

Hi Rob,

> I would only want to be sure that the system will still function well if
> the SD card was disconnected in flight.

right now the only things that fail in flight if we lose the microSD
card are DF logging and terrain following.

Cheers, Tridge

[Leo Ran]

Hi Nick,

Heard you have got the Rev3 of PX4? Why I can not find the link in Mouser?

[Nikolay Arsov]

Hi Leo,
The problem is not just in Mouser, but with DigyKey, farnell, etc.
None of them give the info about the STM32F427VIT6 revision number....it is just like a Russian roulette.
I got 2 batches from Mouser and both were rev3.
This is the link I use to order - http://www.mouser.bg/ProductDetail/STMicroelectronics/STM32F427VIT6/?qs=%2fha2pyFaduhXhUhb2nakax7240hosYlHWJ5PNRqgdMPu0f8itkCV%2fQ%3d%3d
BR
Nick

[Philip Rowse]

I wonder if we could pressure them to issue a new part number....   It would make life much better...

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER 

    3D Robotics

    +61 (0)427 326 366

    website | facebook | Instagram

--

[Nikolay Arsov]

Hi Philip,
I e-mailed several times to Mouser, DigyKey and Farnell asking them to place a note with the revision code they offer, but without success.
Although I succeed to buy rev3, there wasn't a note what rev the chips are. I think a note to ST can push them ask their distributors to add this info to their websites.

[Robert Lefebvre]

I wonder if all the Rev 1 and 2 are running down in stock.  You're probably likely to receive Rev 3, but they don't want to specify that as they can't be sure if somebody digs out an old box found in the back of the warehouse.

--

[Philip]

Yes, I am glad you have managed to get the Rev 3 so far :)

My main concern is the 100's of thousands of existing users... There is no need for us to make their hardware redundant before its time.

So the issues here... 

Are people willing to lose some USB functionality in exchange for a couple of years of product life extension? 

--

[Robert Lefebvre]

I think the decision is easy.

We keep going with USB until we run out of resources.  Then, users will have a choice: Stick with the last release.  Or, take future releases with USB turned off and just accept that.  Or buy next rev of hardware to keep USB.

[Philip]

@Rob. It's about user confidence... We are at that point NOW! 

If we find a way around this, it's a win win!

Sent from my iPhone

[Chuk Rhodes]

If you are buying in the 100s of them, or more, you should be able to get the rev you want. Call and talk to a sales person. At least for Digikey, I know they will work with you. You can even do scheduled delivery, if you knew you would buy say 250, 4x a year, you'll get the 1000 price each time. The more you buy, the more leverage you have.

[Philip]

I think we have covered future boards.

Can we please focus back on the 1000's of thousands of existing boards...

On 17 Nov 2015, at 09:36, Chuk Rhodes <chukr...@gmail.com> wrote:

If you are buying in the 100s of them, or more, you should be able to get the rev you want. Call and talk to a sales person. At least for Digikey, I know they will work with you. You can even do scheduled delivery, if you knew you would buy say 250, 4x a year, you'll get the 1000 price each time. The more you buy, the more leverage you have.

--

[Chuk Rhodes]

Looks like it's either serial/uavcan bootloader, or load from uSD card. Pulling the card to download large logs or upload firmware isn't the worst idea.

The limitation seems to be accessing the second bank of flash with USB activity (PA12)... what about a USB mode for file access only, ensuring that code is in the first bank. To upload firmware, you transfer it to the uSD card, then the uSD-only bootloader could take it from there?

[Linus Casassa]

So can we enable USB for firmware updates, sd card for logs and just have a serial telemetry for everything else? This is my current use so I would not be affected if the usb is disabled on normal operation. Or just use sd for firmware updates if usb can not be used in boot loader mode. I definitely prefer getting the double flash space instead of the usb even if that means that firmware update will get a little more complicated.

Regards,

Linus

On Tue, Nov 17, 2015 at 5:53 PM, Chuk Rhodes <chukr...@gmail.com> wrote:

Looks like it's either serial/uavcan bootloader, or load from uSD card. Pulling the card to download large logs or upload firmware isn't the worst idea.

The limitation seems to be accessing the second bank of flash with USB activity (PA12)... what about a USB mode for file access only, ensuring that code is in the first bank. To upload firmware, you transfer it to the uSD card, then the uSD-only bootloader could take it from there?

--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Linus Casassa
+56 9 97776941

[Chuk Rhodes]

Depending on the exact nature of "activity on the pin"... seems like disabling it while the full systems runs should fix it. If there is no "disable", set it to tris in, or output low - U302 would probably protect it from worst case scenarios.

When it boots up, it could check for USB connection, and enter "file access" mode. If not found, disable USB. Then check for firmware file on uSD, compare a signature in ROM, if different, start the bootloader for it, if not or signatures match, continue to boot to flight mode. That would leave a fairly small bootlog to download over telemetry to confirm/not the update.


It may be useful to have a MAVlink (and/or shell command) to "shutdown to USB mode" for getting logs, effectively pausing or just stopping the full system.

[Philip Rowse]

this is exactly what we had discussed doing when the Pixhawk 2 project started... we actually discussed the potential of sending the latest firmware slowly via telemetry whenever it was available, then just triggering an update via setting a parameter... nothing came of it, but it would be a good option.... there is already a method of updating the bootloader from the SD card.... so no reason we couldn't do similar for the main program....

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER

    3D Robotics Australia

    +61 (0)427326366

    website | facebook | instagram

[Andy Piper]

FWIW I think USB is pretty essential for setting up a vehicle right now. Having to do that over wifi or bluetooth would be a real PITA. At least with USB you have a very high degree of confidence that things are going to Just Work.
I have bluetooth modules on both my copters, but it does interfere with RC and I am often turning it off. I always switch to USB if I want to be confident about what I am doing.
I pretty much gave up downloading log files a while ago - pulling the card is much easier and more reliable.
I think at the very least you should consider ensuring the codebase continues to be modular enough that people can still build with USB support if they want to at the expense of other features. The kitchen sink approach is always going to bite you at some point. Just look at the complaints about pulling APM support (although obviously there were other reasons for that - not just size).

andy

[Michael du Breuil]

I can see yielding USB provided its available for firmware updates, and setting initial parameters. The only reason for requiring it for setting parameters, is that there needs to be a mechanism to recover from crazy/wrong settings on any other communication port (and other misconfiguration), and I'd like to be able to set the key for mavlink signing over a wired connection initially. Even if booting over USB only offers these two things (without booting APM any further, I think we would be fine).

[Andy Little]

For a wired connection just use a serial port

regards

Andy

[Philip]

The concern is that if settings get messed up, it's nice to have something to fall back to... 

But yes, hard wired is a good option 

Phil 

--

[Andy Piper]

But then you probably need FTDI and a driver - it all falls far short of the convenience and ease of use we have today...

[Philip]

Inconvenient, yes... But better than needing to upgrade perfectly good hardware.

--

[Michael du Breuil]

This is true. If we lock serial 5 (or some other serial port) to only have one setting (Baud 115200 etc and speaks mavlink)  then it would be much easier to move away from the USB, as the ability to recover settings would be assured on some level. (With the caveat of needing a FTDI cable, but still, thats a fairly cheap investment as compared to a new auto pilot, and most people generally don't need it).

[john...@gmail.com]

At 115200 serial would be very slow (factor of 10) compared to even then lowest USB speed (1.5Mbit).

[Philip Rowse]

What is the fastest that an FTDI can work with Pixhawk?

◤PHILIP ROWSE

    LEAD SYSTEMS ENGINEER

    3D Robotics Australia

    +61 (0)427326366

    website | facebook | instagram

[john...@gmail.com]

According to the ST datasheet max speed for UART1-6 is 11.25Mbit and the rest is 5.6Mbit. FTDI does up to 12Mbit on the UART interface.
But that's just the hardware. Not sure what the current software divers will allow.

[Andy Little]

You should be able to get 1.5 Mbps from PC serial port I think. At least I can on my weedy Linux Intel Atom Netbook ( which from tests translates to around 850 kbps throughput on a loopback anyway

regards

Andy

[Linus Casassa]

And how about the signal integrity with the cables between the FTDI and Pixhawk? We will need to test what is the max speed with bad/normal cables.

[Nikolay Arsov]

Hi guys,
Are you OK with cables? Is it easy for you to calibrate your UAV connected with cables?
Please say "good bye" to cables and go wireless - ESP8266 .... cheap ( just $3 ), easy to manipulate and fast enough.

[Tom Pittenger]

Yes, we know wireless is good. So, why include USB on your new XRacer? (hopefully we're back on topic now..)

--

[Bill Bonney]

> So, why include USB on your new XRacer?

Probably to flash the FW, since that’s how its done at the moment. The XRacer can plug-in a ESP8266 directly on the 2x5 header. So it’s a good target for FW OTA test bed.

The only time i ever connect a cable to my pixhawk/apm2.x or any other HW is to flash. I generally use WiFi or telemetry link for all other things. Log Download over WoFi is fast (but pulling the SD card is quicker.)

I think we should enable (i’m sure its there anyway) serial bootloader, then we can connect WiFi or whatever device to flash firmware OTA.

we should then look at delivering one image for older STM chips that has usb, but less features enabled, and one with USB disabled with all other features. That’s a clear upgrade path.

If somebody come up with a way to run USB for bootloader only, that great. But what we are avoiding in precious man hours bit twiddling images to get them smaller. Those hours are spent getting OTA FW updates working which is better for everybody.

The short-term is to look at flashing using a serial cable. (it might be that this is just a FW FILE TRANSFER over MAVLINK to the SD CARD and a reboot, as that is probably the most reliable process.

I might go digging around in the PX4 repo to see what enablers they have for updates.

Bill

[Tom Pittenger]

Bill,

USB+Serial bootloader was merged in 2 weeks ago

https://github.com/PX4/Bootloader/issues/33

[Philip]

Ok, so anyone willing to do some Bootloader tests and DF tests, with both wifi and FTDI? 

I think wifi may be a perfect option here, thanks Nick.

Would be great to put some names against this, and verify that we can safely get the 2nd Meg back.

Phil 

[Lorenz Meier]

I have been coordinating the wireless boot loading effort for PX4, which is what you guys would be using as well. I've also spun up a group looking into coercing the ESP8266 Firmware to comply. More people would be warmly welcome - I'm convinced we need a Dronecode ESP8266 image.

Please contact me via Gitter on https://gitter.im/PX4/Firmware, Google groups on http://groups.google.com/group/px4users or directly via email at lor...@px4.io. Its always a good idea to cross-post STM32 related hardware discussions to PX4 users (the group has literally as many members as this list) or to even start the discussion there, as that's the community maintaining that software and hardware layer.

The next step we'll do is to work out the maximum baud rate of the ESP8266. We saw hiccups when we tried 921600 baud on it. We need to investigate in parallel the influence of Wifi on the RC signal for people wanting to run both.

The hardware architecture I did for the Pixhawk XRacer for Nick and Phil is solving this by provisioning hardware-shutdown capabilities to the ESP8266.

-Lorenz

[Michael du Breuil]

As long as whatever solution we come up with for a wireless interface allows a wired connection as well it makes sense. I really don't see the benefits of jumping ship to a pure wireless approach. Adding another WiFi link/radio to the aircraft will be unacceptable for some use cases, or not be practical to leave after setup, leading to as much messing with hardware as if there was a cable.

With all the proposed ESP8266 solutions how does the architecture work? Is the aircraft the AP and you connect to it, or do you somehow tell the aircraft the appropriate SSID and credentials to get on you're existing network? If this infromation is somewhere, I apologize I just haven't noticed it.

With regards to the interference with RC Lorenz mentioned, I've done testing with a combination of different WiFi systems and demonstrated a 33% reduction in range on Spektrum RC gear when operated near a 100mW WiFi system (At higher transmit powers or with directional antennas the effect gets worse). (The testing was all done at the time for the AUVSI sUAS competition).

[Andy Piper]

+1

It's worth noting that GoPro cameras originally used WiFi for coms/control and were configured as an AP. My personal experience was that this was very unreliable and a bit of a pain to use. Interestingly the newer cameras all support bluetooth now - I suspect because the convenience outweighed the range issues. I see reports of WiFi direct and Bluetooth 4 which both apparently use 802.11 for transmission, so maybe the convenience issue is fixed in newer hardware.

[Nikolay Arsov]

Hi guys,
I don't want to force anybody to use the 8266 during flight. What I mean is that it is the cheapest wireless connection for bench/field setup/testing.
You may or may not use it during flight. When flashing the bootloaders I always use the JTAG = no problem. For flashing the firmware the USB/SERIAL/microSD = all they are fine, but for calibration.......cables = disaster.
As I'm testing a lot of boards, I killed several cables :-( . A good USB cable costs about $10. Just to recall, ESP8266 board costs < $3
Cheers!
Nick

[Luis Vale Gonçalves]

@Nick

Problem with the ESP8266 @$3 is which one :) A quick survey on eBay shows lots of variations. The possibility of shutting down the ESP8266 is crucial to avoid more "noise" on the 2.4GHz band, specially now, with the newer ETSI regulations /EU limitations on this part of the RF spectrum.

[Nikolay Arsov]

Hi Luis,
Yes, there are a lot of newer versions of ESP-01 board. On XRacer V1, there is a socket for that board as it is the cheapest.
About the 8266 power down, I made a connection from its PD ( power down ) pin to the FMU. Thus one can use it or not during flight.

[Chuk Rhodes]

It does appear that the 8266, at least for this purpose, is just Wifi-Serial adapter. Another flavor of XBee, 3DR radios, etc. All require a serial bootloader if they're going to replace USB, and all are much more limited in speed than USB.

Whats really needed, if transferring a large file over wireless, is checksums and resends. You don't want to spend 20 mins sending a file, to have it fail and have to start over again.

Having the file go to SD card first could save some headaches in the long run, so you don't get "stuck" in serial bootloader.

So the fastest way to drop USB is serial bootloader, the question is which serial port? I'd prefer 5, the console port, since it would eliminate unplugging other devices already plugged in. I have made adapter cables for FTDI and 3DR radios already, easy and cheap. But it would also make sense to have it work over Telem1/2 as well.

The better way would be SD bootloader, requiring a robust way to transfer files over serial/wireless, which would benefit downloading of logs as well. Or simply pull the SD card and transfer without serial/wireless.

The USB at Boot idea I mentioned would be ideal, but I'm sure that will take much longer to implement/debug than either of those options.

[Tom Pittenger]

I'm in favor of bootload via SD card.

Transfer file over MAVLink (900/433/WiFi) to root dir with specific name that bootlooader checks on next boot. Application later would delete the file if it boots up and that file is present and matches the current running version. That keeps the bootlooader from constantly losing the file on ever boy. Maybe a different file could be used as a flag instead? Details we can figure out later.

Terrain data does file transfer over MAVLink already so many of the blocks are already there, just need to add a FAT32 read file option in the bootlooader. If it won't fit, remove the USB driver in the bootlooader.

Another special file could trigger a factory reset for recovery.

I think that addresses all the concerns we have for removing USB, right? We get boot loading over wireless or wired or via manualy copying file to SD and a recovery option.

[Bill Bonney]

I agree

I don’t think FW update using a radio a serial replacement technology is a good ‘consumer’ type approach. Too many things can go wrong with interruptions to the process.. Saving the new FW image file to the onboard SD CARD is the best/safest experience.

As DIYD option using a serial bootloader via WiFi serial replacement  or plug in cable is good option for convenience, You might just plug the module in to do the FW update and then remove. That’s still easier than finding a cable long enough!

@Lorenz: I have some of these ESP boards sent to me recently so I am happy to help test some fw and contribute. I’m looking at finding an image that is configured to send UDP packets to connected devices.

I agree, we can disable USB for devices that won’t work, as we alternative options for these ‘legacy’ boards.

Bill

[Thorsten]

The USB at Boot idea I mentioned would be ideal

From a users perspective this seems to be the best option.

For UAV based mapping I need every log file for geotagging. Generally, and especially with GPS raw data, log files are getting bigger and bigger. Even with a USB connection it takes a while to download a log. So especially for downloading the logs USB at Boot would be perfect.

For calibration WiFi would for sure be perfect. But this is only required from time to time. And there might be interference issues with GPS, RC and telemetry. Hence it would be great if WiFi could be - physically - switched on/off if required.

Anyway, if it would require a new autopilot to keep things as is and just move on, which would be the best option, I would have no problem if older APs would not receive any further firmware updates.

Just my 2 non-dev cents

[Chuk Rhodes]

I've been looking into the NuttX usbstorage example, and found something fairly useful on this...

Even with Copter firmware disabling USB, the USB bootloader still works.. most reliably by plugging in the Pixhawk to USB while the uploader is running. It occasionally catches with "reboot" in the console...

Adjusting rc.APM with "set deviceA /dev/ttyS5" doesn't exactly work as expected, but some tweaks in code fix that.

The usbstorage example kind of works, only after the system is booted, not in the rcS where it would be most useful. Although not needed for firmware from sd, it would be useful for logs.