APSync R.Pi3 web interface not working

I have a Raspberry Pi 3 running the October release APSync image connected to a Pixhawk 2.1 running AC 3.5.3.

From a laptop connected to the pi wifi I can connect with QGroundControl, and motion of the PH shows on the HUD. Based on this I believe the pi and the PH are talking to each other.

However when I connect to the apsync web interface on 10.0.1.128, almost none of the features are working. No logs to download, no files to browse, no sensor data, no parameters. The only thing that seems to work is the button to reboot the pi. The fact that this one function in the web interface does work gives me hope - what am I missing for the rest?

I have a Raspberry Pi 3 running the October release APSync image connected
to a Pixhawk 2.1 running AC 3.5.3.

From a laptop connected to the pi wifi I can connect with QGroundControl,
and motion of the PH shows on the HUD. Based on this I believe the pi and
the PH are talking to each other.

Do you have a second source of telemetry which may be confusing the
situation?

No. The only connectors on the PH are power, GPS1, RC IN, and Telem2 which is connected to the pi.

Slight correction to my original post, in addition to the reboot button working, the “FC MAVLink count” field on the System Information page seems to be working - it increases by roughly 3 every second.

Slight correction to my original post, in addition to the reboot button
working, the “FC MAVLink count” field on the System Information page seems
to be working - it increases by roughly 3 every second.

What address are you using to access the web interface?

10.0.1.128

Is this working correctly for you?

I did some testing to rule out a browser issue. I’m getting the same results with Chrome and Safari, both on macOS and iOS.

I’m still learning the code … In the file start_apweb/screenlog.0 there are many “Denied origin: [http://10.0.1.128]” messages. The only place I can find that logs the denied message is the function check_origin in web_server.c. Why is the first strcmp comparing the host from the origin header to “http://10.0.1.”? Should it be strncmp()?

I tried changing the origin network test to strncmp to only compare the characters of the /24 network address. Things are now working much better. Specifically, the dataflash logs, filesystem, flight parameters and system control pages are all working.

I’m still not getting any live sensor data on the system status or calibration pages. Need to investigate this.

10.0.1.128

Is this working correctly for you?

Yes, it is. It’s also working for a few other people I know of.

I did some testing to rule out a browser issue. I’m getting the same results
with Chrome and Safari, both on macOS and iOS.

Cool.

I’m still learning the code … In the file start_apweb/screenlog.0 there
are many “Denied origin: [http://10.0.1.128]” messages. The only place I can
find that logs the denied message is the function check_origin in
web_server.c. Why is the first strcmp comparing the host from the origin
header to “http://10.0.1.”? Should it be strncmp()?

Or 10.0.1.128

The fact this is working for anybody is a real concern actually.

The file https://github.com/peterbarker/APWeb/blob/master/cgi.c does not call check_origin. But the source tree that came with the pi image does, and that source matches the binary on my pi. Maybe the people who have had success were building from github source?

I figured out how to get live sensor data in the web interface - I just need to start QGroundControl on the same laptop. It doesn’t need to keep running, so long as QGC has run for a few seconds since the pi booted, then the APWeb interface displays all the sensors. Is this is how it’s supposed to work, with QGC responding to the UDP broadcast and triggering the sensor data?

I figured out how to get live sensor data in the web interface - I just need
to start QGroundControl on the same laptop. It doesn’t need to keep running,
so long as QGC has run for a few seconds since the pi booted, then the APWeb
interface displays all the sensors. Is this is how it’s supposed to work,
with QGC responding to the UDP broadcast and triggering the sensor data?

No - the interface should work without QGC running.

The original check - which I assume you’ve bypassed - it just utterly
broken. It seems for some reason your browsers were sending along Origin
headers when everybody else’s aren’t - that’s a bit of a mystery.

Are you running the files off the drone itself or a local copy?

Weird. I could understand if my laptop had some config that made it different, but I get the same behavior on iOS.

New test: I start Chrome on my laptop, go to 10.0.1.128 System Status->IMU. The three graphs are moving but there is no data. Then leaving that connected and running, I also connect my iPad to the pi wifi and start QGC. Immediately over on the laptop the three graphs have live data. There is something on my system that’s stuck until someone somewhere connects and runs QGC.

Not sure exactly what you’re asking. I have a Pixhawk 2.1 on the bench with telem2 attached to a pi 3. The pi was set up using the Oct 5th APsync image. Apart from the check_origin workaround I haven’t changed anything. My laptop or iPad connect to the pi using the on-board wifi on the pi.

10.0.1.128

Is this working correctly for you?

I did some testing to rule out a browser issue. I’m getting the same results
with Chrome and Safari, both on macOS and iOS.

OK, now I’ve replicated this issue. I simply tried chromium-browser
and it replicated out of the box. firefox didn’t replicate - and that’s
possibly quite a bad thing for firefox…

I ahve modified the APSync testing document to indicate that the APWeb
testing has to be covered using multiple browsers.

I’m still learning the code … In the file start_apweb/screenlog.0 there
are many “Denied origin: [http://10.0.1.128]” messages. The only place I can
find that logs the denied message is the function check_origin in
web_server.c. Why is the first strcmp comparing the host from the origin
header to “http://10.0.1.”? Should it be strncmp()?

Probably just a strict 10.0.1.128 is probably sufficient. It certainly
is for me! I believe you’ve already done that, 'though?

  No - the interface should work without QGC running.

New test: I start Chrome on my laptop, go to 10.0.1.128 System Status->IMU.
The three graphs are moving but there is no data. Then leaving that
connected and running, I also connect my iPad to the pi wifi and start QGC.
Immediately over on the laptop the three graphs have live data. There is
something on my system that’s stuck until someone somewhere connects and
runs QGC.

OK, I’ve replicated this now and can chase it, thanks!

The cause is the lack of telemetry stream rates on the PixHawk device.
When you connect a GCS - any GCS AFAIK - they talk to their target UAV and
fiddle with the stream rates to their satisfaction, and everyone listening
in “benefits” from these changes - so in this case APWeb running on the CC
starts to get traffic which is then returned in the request to the web
browser…

Currently not sure what the correct fix is. Probably to have APWeb have
some configuration indicating it should request streams from the
autopilot.

Yes I have it working now. Thank you for the followup on both these issues.

FWIW I’ve pushed up new code for the apsync variant of APWeb here: https://github.com/peterbarker/APWeb/tree/apsync

The new code will attempt to set the stream rates for the messages it needs if the current stream rate is less than it desires. Currently this is based off the APWeb refresh rate - that might prove to be a problem - we’ll have to see…

1 Like