Wi-Fi setup RFC

[vldpro]

Summary

This document describes the new messages for Wi-Fi setup through mavlink protocol. With these messages GCS can switch Wi-Fi between two modes (Client/AP), save/delete networks to/from vehicle and requests current status of Wi-Fi.

Rendered

[LorenzMeier]

On a first pass, this looks good. @mavlink/qgroundcontrol any feedback?

[DonLakeFlyer]

That would have to be Gus. I don't know anything about this stuff.

[dogmaphobic]

I'm not sure it makes sense to handle this through MAVLink. Given that this is WiFi (inherently TCP/IP), it might make more sense to use standard HTTP forms (POST/GET). These things invariably have an HTTP interface anyway. It just makes it more complicated on the device's end.

It also makes it quite unambiguous as the (MAVLink) WiFi interface is not going to be there if you plug a USB cable directly to the vehicle.

[vldpro]

I think the use of HTTP is not the only proper way to implement Wifi configuration. If display settings are in browser, it makes different interfaces to configure and monitor the vehicle Wifi component. That might not the user-friendliest solution. A user would need to have a browser as well as a GCS to control the vehicle. Seems like an overkill.

If done in GCS, we would need to implement the new logic for interaction through HTTP with vehicle, then. But we already have MAVLink. Our goal is just a simple Wifi configuration message set which is designed as addition to WIFI_CONFIG_AP message. All other settings can be passed using mavlink parameters. It just makes for user a common interface (for example, in QGC) to configure Wifi like other components. In case the vehicle is connected using USB cable, user can still configure Wifi component, if it is present.

[dogmaphobic]

If done in GCS, we would need to implement the new logic for interaction through HTTP with vehicle, then.

The same additional work will need to be done to handle these new MAVLink messages. They are new messages with their own responses, therefore you cannot rely on the existing "command" messages. It's a lot simpler to add this logic to QGC than impose this to a micro controller (assuming it already has an HTTP interface for setting it up, otherwise this is all invalid).

In case the vehicle is connected using USB cable, user can still configure Wifi component, if it is present.

No, you cannot. If you connect to the autopilot directly (USB or UART), you will not have access to the WiFi component. At least not normally.

[vldpro]

In addition to the micro controllers, there are linux boards. In our case we have one, which runs the mavlink router and routes messages between several components, one of which is the Wifi Manager (is not a part of autopilot), which configures Wifi and monitors the connection. It's pretty simple to use the scheme mavlink -> router-> components.

In case of HTTP, we should run a HTTP server on the board and make a new path for communication between the vehicle and GCS. Also, could you describe your look at the problem more detailed? Why do you think that HTTP is more suitable? Any examples?

[dogmaphobic]

Why do you think that HTTP is more suitable? Any examples?

It's more suitable when the WiFi component already provides an HTTP interface for setting it up. If yours doesn't, than this is all invalid. How you would set it up is an interesting question though. If you can't set it up unless you use MAVLink, how are you going to connect to it so you can have MAVLink traffic?

In our case we have one, which runs the mavlink router and routes messages between several components, one of which is the Wifi Manager (is not a part of autopilot), which configures Wifi and monitors the connection.

That seems to be an exception rather than a rule. That means the only way to configure WiFi is to connect a USB cable directly to something. That seems counterintuitive. Good luck setting it up with an iOS device for example.

That's primarily why I thought using HTTP would make the most sense as your are setting up the transport layer, which carries MAVLink. It's one level below. You need WiFi functional before you can send/receive MAVLink. That's usually done at the OS level and not the application level. The WiFi module would have to provide some sort of interface for configuring it that doesn't depend on MAVLink, otherwise you would never be able to connect.

Either way, if it must be MAVLink, the main issue is that the existing command protocol, which is used throughout QGC cannot handle anything but numbers. There is a new PARAM_EXT protocol that should be used for everything but that would imply quite a bit of changes. Configuring WiFi however, is no different than configuring cameras, which already uses the new PARAM_EXT protocol. Adding new messages just for WiFi will only add complexity as QGC will need to handle new messages and new response mechanisms for one, exceptional case and nothing else.

So, should we add a new set of messages/responses just for WiFi or make use of an existing, extended command protocol that is already in place? Why is it important to configure something at the application level that would otherwise have to have an alternate (OS level) interface for configuration?

[hamishwillee]

@dogmaphobic My summary of the above is that you are not convinced of the use case, but if it needs to happen it should be done using PARAM_EXT protocol rather than custom messages because that will be a more "generic solution" - correct?

@vldpro Are you happy for this to be closed or do you wish to respond and iterate further?

[dogmaphobic]

My summary of the above is that you are not convinced of the use case, but if it needs to happen it should be done using PARAM_EXT protocol rather than custom messages because that will be a more "generic solution" - correct?

It's more than just a case of a generic solution. These sort of settings belong outside the scope of MAVLink (which is the payload of the link). I'm not sure any WiFi configuration belongs within the GCS. I still don't understand how you would connect to the WiFi to configure it in order to connect to it...