[ESP8266 Bridge] [BUGFIX] Add check for WIFI params for ESP8266 bridge

[zdanek]

Description

When using WIFI ESP8266 bridge for the first time, QGC was not checking for existence of WIFI parameters. It resulted in SIGSEGV

FactPanelControllerLog: Missing parameter: "240:WIFI_PASSWORD1"
Signal: SIGSEGV (Segmentation fault)

Test Steps

Create fresh build, with fresh ini config, connect ESP8266 bridge to Ardupilot board.

This fix checks for existing WIFI params.

[DonLakeFlyer]

This seems a bit like fixing the symptom not the problem. How come these parameters are missing? Aren't they required?

[zdanek]

TBH, I don't know. Are those nested inside Ardupilot? Or in QGC? And, can QGC (GS in general) set new params? That is, send from external world and AP will save it? It's possible for LUA scripts to add new params, and they will be seen from now on in AP parameters list.

[DonLakeFlyer]

Those params should come from the device itself. When QGC does a request for parameters from the vehicle it should get these as well.

Somehow it got this:

            //-- Is there an ESP8266 Connected?
            if(_vehicle->parameterManager()->parameterExists(MAV_COMP_ID_UDP_BRIDGE, "SW_VER")) {
                _esp8266Component = new ESP8266Component(_vehicle, this);
                _esp8266Component->setupTriggerSignals();
                _components.append(QVariant::fromValue((VehicleComponent*)_esp8266Component));
            }

But not the other parameters. That is very odd.

Can you help clean this code to at least tell the user that the UI isn't going to work? Right now it's just gonna show nothing in the UI for the wifi ssid/password fields. And they won't work. There should be some sort of 'valid' bool on the controller or something which indicates the whole things is hosed up. And then the ui lets the user at least know.

[DonLakeFlyer]

When you run a build with your fix. Do you still get a parameters missing error when you go to the setup page?

[DonLakeFlyer]

@zdanek Any updates on this?

[zdanek]

@DonLakeFlyer I'm back with this.

Apparently I found original problem with params. ESP8266 bridge is popular in several flavors, best of them is Beyond Robotix Kahuna. I used that one as a base. Still I introduced many fixes and improvements for my own use. Nevertheless, it had a few params "misspelled", for example WIFI_PASSWORD instead of expected by QGC WIFI_PASSWORD1.

Do you know where is any "official" spec of those params? I dug through mavlink docs but found nothing.

So, after that fixes in ESP8266 bridge firmware, it works again in QGC but I see that UI can be a bit adjusted. Also WIFI mode set to "STA" doesn't disable AP fields. Baud rate is also incorrect - might be problem in QGC or in ESP8266 bridge.

And now the best part - with that params problem I accidentally discovered a nasty "bug/feature" in QGC that effectively blocks fetching component's params other than Ardupilot FCU component (autopilot). I will create a bug report and I can do a fix.

The problem is that after connecting to a Ardupilot Vehicle, QGC fetches all params via FTP. That setting effectively blocks broadcasting request for param list from components attached to that particular Vehicle. They should react on MAVLINK_MSG_ID_PARAM_REQUEST_LIST or MAVLINK_MSG_ID_PARAM_REQUEST_READ sent to system_id and component=0 (broadcast). But this never happens, as QGC is using FTP fetch first. If successful, it gets all AP params but never asks broadly for parameters of all attached components.

If I disable ftp (just set ParameterManager::_tryFtp to false, instead of vehicle->apmFirmware()) it fetches successfully ESP8266 params as well with "classic" (and slow) way.