Refactor component code, verify logging, and implement reset pin

[dennisss]

• The COMP_ID_UDP_BRIDGE message handling is moved from the GCS class to it's own file. Should be cleaner and easier to maintain. Also, these messages can now be handled coming from both the GCS and the Vehicle side
• In the HTTP API, the logger now returns the correct length (based on decoded string size) and the correct start position relative to the absolute start of the log at boot.
• Reset to Factory pin now triggered by a low signal on the GPIO02 pin. It is handled by an interrupt, so resetting should be possible while hanging in setup(). This has been verified to work.

[dogmaphobic]

Dennis, this is great! I've been working on the UDP data loss and have reworked the buffers quite a bit. I had started this before your last commit and had put it on hold so I could merge your last additions. I don't think there will be merge conflicts but given that both these changes are rather large, let me wrap my changes first. I should be done within the next few hours.

[dogmaphobic]

There, the changes are in but you will need to rebase. Let me know if you need any help.

Thanks!

[mzahana]

Thanks guys for the effort. I have experimenting with the firmware, and I noticed the following. In a lab enviornment, using linksys router, i fiest connect to pixracer in AP mode. Works fine. Then in QGC i set the STA mode. My laptip can always connect to the external router with no loss. The esp, however, connects for a short time period and then, QGC losses connection.

Any ideas on what could be the issue?

Thanks

[dogmaphobic]

The esp, however, connects for a short time period and then, QGC losses connection.

Any ideas on what could be the issue?

Not really. What I did notice here is that once (within QGC) I change from AP to STA, I have to actually power cycle the ESP for it to work correctly. Once it boots back up, it connects to my router (Asus RT-AC88U) and works solid from that point on.

[mzahana]

After power cycle, it connects to my router and i can connect via QGC for short time then it disconnects. Surprisingly, it works just fine with the same router, but at home!!

[dogmaphobic]

After power cycle, it connects to my router and i can connect via QGC for short time then it disconnects. Surprisingly, it works just fine with the same router, but at home!!

Do you have a 2.4GHz RC radio running next to it? I use a 430MHz radio to avoid the interference.

By the way, I now remember you (or someone) asked if the ESP works in the 5GHz band. No, it doesn't.

[mzahana]

In the lab there are many 2.4Ghz APs in the neighborhood, but I am not using 2.4Ghz RC radio. The thing is, I still can connect to the router from a laptop or mobile phone!

[dennisss]

I've rebased my changes. Should be good to merge.

Regarding the STA disconnects, my best guess is that that the networks are channel hopping or in some way interfering to sporadically disconnect the ESP. Right now STA mode doesn't gracefully handle disconnect/reconnect events, although I was planning on adding some support for that soon. For computer and mobile phone likely have more tolerance to failures.

[mzahana]

Thanks. It would make the firmware more complete/robust to have the reconnect feature.

Would TCP solve such issue?

[dennisss]

If you are doing telemetry or data streaming, TCP would probably introduce a lot of latency in to it. But aside from that, I think there are two separate issues here: one with resending lost packets (which TCP would solve), and ensuring that all the sockets reconnect after a wifi reconnect.

You can try out TCP by seeing if you can access the HTTP server running on your ESP. If you can access it, that would probably be a better test for whether or not the ESP is disconnected or if the UDP is losing too many packets. I'd also try pinging the ESP ip from a terminal and seeing if you get any response to completely take rule out issues with the servers running in MavESP.

[dogmaphobic]

@dennisss Thanks a bunch! I've packaged the firmware and updated the "standard" link. Now I need to add the code to the PX4 firmware to lower GPIO02 on command so we can Reset To Factory from QGC.

I got UDP drops way down but they still exist. Interestingly, I noticed that when in Station mode, there are zero drops. From there I started investigating and noticed that when in Access Point mode, the lower level code takes too many cycles away from our main loop. I'm now disabling DHCPD once a client is connected to minimize extra code running unnecessarily but there is still room for improvement if we find what in SoftAP mode is causing so much load.

[mzahana]

I can see that the drop rate is getting better (less drop). However, the disconnection issue is horrible. I removed all the 2.4Ghz RC radios, and still disconnects. And when it disconnects, it disconnects forever. I believe that the existence of many devices that use 2.4 bandwidth in the vicinity is a major issue, but still laptops/mobile phones are robust against that.

I guess a major feature would be to have a robust firmware against the disconnection issue. I would love to contribute to solve this, as I need it for my project of multi-pixhawk control, but I am not strongly familiar with the communication protocol. If you wish, you can give me some pointers to where the code exactly needs modifications, and I can try.

Thanks for the efforts.

[dogmaphobic]

This is all at the very low level SDK and it's not simple to track it down/debug. If you have an ESP-12e, you can add serial debug output on UART2 (GPIO02) to help "see" what's going on. Enable debug mode in here:

https://github.com/dogmaphobic/mavesp8266/blob/master/src/mavesp8266.h#L72

Noting that you must then use UART1 to link to the Pixhawk/PixRacer (UART0 is the USB link).

Here is a place to start:

https://github.com/esp8266/Arduino/blob/master/tools/sdk/include/user_interface.h#L225-L239

[dogmaphobic]

@mzahana Please, take a look at #20 and see if it makes any difference.

[mzahana]

@dogmaphobic Thanks for that. I tried it. It seems to me that it worked better before #20 !! I don't know if that makes sense!

I logged into my router http and looked at the clients connected, and I could see the ESP connected with 100% signal strength! However, I can not even use http://192.168.0.117/getstatus, and QGC cannot connect. The ESP IP ends with 117.

I checked the log and here is what i get

Actually, in one of the trails before #20 , I changed the router (D-Link) and tested the ESP, and stated connected for 30 minuted before I manually powered it off.! That moment I was too happy!

What could be fishy in #20?

Thanks again

[mzahana]

I just noticed something! I have been using platformio run -e esp12e -t upload to upload to this ESP board, which I guess is ESP-01, right?

but the argument passed to platformio run is esp12e NOT esp01. However, the build and upload process do not show errors!

Would that make an issue?

[dogmaphobic]

Yes, that's an ESP-01. You should be using esp01_1m. The esp01 is for the original ESP-01 boards with only 512kB of flash memory (cannot handle OTA upgrades). If you are successfully uploading the firmware using the browser, you can be certain your board has 1MB :)

[mzahana]

Thanks. Does #20 work with you flawlessly?

[dogmaphobic]

Thanks. Does #20 work with you flawlessly?

Yep!

[mzahana]

@dogmaphobic And what is the esp board that you use with Pixhawk?

[dogmaphobic]

I have one identical to yours on a PixRacer and an ESP-05 on the Pixhawk.

[mzahana]

and both work fine?

[dogmaphobic]

Yep!

[mzahana]

Tomorrow, I will re-flash using esp01_1m and compare between #20 and the build before #20, and see how it goes.

[mzahana]

Is there a good ESP port with external antenna that can enhance the range?

[Saxin]

yes, ESP-07 module have UFL conn., need to remove 0 ohm resistor. (After removal do not run without antenna connected)