Late January Release of APSync

Following the release of APSync in mid-January, a follow-up release has been done to address some of the inconsistencies in the original images.

Most notably, the --mav10 parameter was missing on the MAVProxy instance running on the APSync image on Edison and RPi.

This release also moves APSync to:

  • use a common username/password for each image (apsync/apsync)
  • use a common hostname (apsync)
  • use a common filename format for the images (apsync-)

WiFi Access Point name and key are unchanged (ardupilot/enRouteArduPilot)

I’ve updated the -latest links: (http://firmware.ap.ardupilot.org/Companion/apsync), but these are the current URLs:

Edison: http://firmware.ardupilot.org/Companion/apsync/beta/apsync-edison-20170130115647.tar.xz
TX1: http://firmware.ardupilot.org/Companion/apsync/beta/apsync-tx1-201702010025.img.xz
RPi: http://firmware.ardupilot.org/Companion/apsync/beta/apsync-rpi-20170130063043.img.xz

While testing the TX1, I found an issue with the TX1 image.

To make it able to connect to a Pixhawk you need to ssh onto the TX1 (user:apsync, pw:apsync) and edit the ~/start_cmavnode/cmavnode.conf file and change the [aseriallink] section so that it’s port is “/dev/ttyTHS1”.

[aseriallink]
type=serial
port=/dev/ttyTHS1
baud=921600
sim_enable=false

For any end users out there, have you gotten the latest RPi image to work with a Pixhawk 1?

My current set-up is a Raspberry Pi 3 with the latest APSync image, a Pixhawk 1 and a Surface Pro 4. The Pixhawk and RPi are connected via USB. The Pixhawk and RPi are independently powered off a 12V battery.

When powered and booted up, the RPi creates a stable access point and I am able to login and see packets sending and receiving. I am also able to SSH into the RPi through the Wi-Fi.

However, I am not able to connect to the vehicle through any GCS. I have tried Mission Planner and QGC. At most, I have an intermittent connection through QGC where it is connected for a second, then disconnects, then connects again.

I have opened up port 14550 through my firewall settings and tried the latest stable firmware versions of Rover and Copter. Same results.

I have a feeling it has to do with my network settings somehow, but I’m not quite sure how else to troubleshoot this one. Any other ideas?

Edit: I also went through the “Testing Regime” in one of the text files for the common Ubuntu directory and got the following:


That “SRTM Download failed” error kept repeating.

A quick addendum to the late-January release.

I’ve uploaded a new version for RPI: http://firmware.ardupilot.org/Companion/apsync/beta/apsync-rpi-20170203112155.img.xz

I have not updated the -latest link for RPi, as I would prefer to keep functionality synchronised between the images when doing those release links.

This version has one-click UDP streaming; if you web-browse to http://10.0.1.128:8000/ you will receive a webpage with a green button labelled “Start Streaming to GCS”. Clicking that will start sending UDP packets to the address of the computer you web-browsed from (or, I expect, the IP address of any proxy you might be going through; don’t do that).

This streaming works (for me!) in QGC for Linux, QGC and Tower on Android and Mission Planner on Windows. Confirmation one way or the other on these and other platforms would be appreciated.

Please don’t get sentimentally attached to the way this sort of thing works on APSync; we’re still in flux! For example - I think we should have an option in that web page to “Always stream UDP to GCS”; that would look at outgoing telemetry streams and send the video stream too. I might even suggest we have that on by default for a better out-of-the-box experience…

@Kevin_K The self-test there seems to show MAVProxy on the CC has a solid connection to the vehicle.

The SRTM problems are something to think about down-the-line; you need either a complete database or an internet connection to supply that data to the vehicle; while acting as an AP the CC won’t have that internet connection.

QGC appears to have an issue where it considers any MAVLink ID it sees as being a “vehicle” (ignoring the fields that define what sort of device the thing is, it seems). So it sees vehicle 254, which is MAVProxy running on the vehicle as a “vehicle”, which isn’t so great. This seems to confuse QGC - a lot.

What does MP on the tablet do?

Are you in a position to try Tower on Android to see if that gives you a solid connection?

1 Like

@peterbarker Thanks for the write up on what’s going on.

I updated to the latest image and was able to browse to http://10.0.1.128:8000/ and turn on/off Mavlink streaming at will. Nice beginning to the additional features!

Got it on the SRTM problem. Funny, I reloaded Rover 3.1.1 and that issue didn’t pop up.

Forgetting QGC, when I load up MP, it just times out when it tries to connect via UDP, Port 14550 (default settings).

I tried Tower on my Sony Z3v and wasn’t able to get a connection either.

Update: I got APSync working on the RPi3 finally. For the users, do NOT connect the Pixhawk to the RPi via USB. A TELEM2 cable harness will need to be made up and connected from the TELEM2 port on the Pixhawk to the UART TX/RX pins on the RPi. I was able to connect just fine to MissionPlanner.

Of note, connecting to QGC is still not quite correct and I wasn’t able to connect to Tower on my Android phone.

Make sure to reboot the Pi between different GCSs connecting. It “locks on” to the first connector and doesn’t seem to let go.

For those that care, to have the Pi use a USB serial device modifying start_cmavnode/cmavnode.conf would be required.

Yes, vehicle 254 drove me crazy until i found this comment, thanks! I have tried Tower (Samsung S4 mini) and it works like charm! Is there any fix/workaround for QGroundStation? I got used to it because I started my tests without cmavnode in the middle and it was working fine…

BTW, having to reboot the Pi to connect from a different GCS is quite bad… if it is broadcasting to 10.0.1.255, wouldn’t it be to allow many GCS to connect?

Anyone know if there is a premade cable that will hook an Edison on a breakout board to the PH1

Yes, vehicle 254 drove me crazy until i found this comment, thanks! I have
tried Tower (Samsung S4 mini) and it works like charm! Is there any
fix/workaround for QGroundStation? I got used to it because I started my
tests without cmavnode in the middle and it was working fine…

Yes, there’s a patch in QGC master which should fix the problem.

BTW, having to reboot the Pi to connect from a different GCS is quite bad…
if it is broadcasting to 10.0.1.255, wouldn’t it be to allow many GCS to
connect?

I haven’t chased this yet :slight_smile:

Thanks Peter! Uh, no hurries… I don’t think that feature is a must at all. BTW, congrats for the awesome work!! :thumbsup:

I’m just starting my project (3 days ago I didn’t know a thing about a companion computers and 3 weeks ago I knew nothing about flight controllers!). I’m an old school RC builder and flyer and I decided to try adding intelligence to one my warbirds… I started with simple stabilisation (CC3D from a colleague), but i want to go farther. I now need to recap my old Linux skills and refurbish a wooden trainer that can fit all the gadgets within (my 1st Raspberry + an APM2.5 from a colleague + USB link). I see a lot of fun ahead!

I have one question though… why do we need cmavnode here? Why don’t we have dflogger get the stuff from any of the MavProxy “outs” and use “master” directly to /dev/ttyXXX?? As I said, I’m just trying to learn, so I’m surely missing something here :smiley:

EDIT: I’m still with the Jan 30th version in case it makes a difference.

We use cmavnode for efficiency. It can split the dataflash-logging data off to the dataflash-logger without breaking a sweat, whereas MAVProxy starts to chew up a ridiculous amount of CPU. There are various reasons MAVProxy does that, some fixable and some not.

We can actually do without MAVProxy entirely (by default, anyway!) if we use cmavnode’s new capability of broadcasting on 14550 itself.

Also note that I chose cmavnode for its simplicity of build system (there’s a lazy analysis for you!). There’s also mavrouter out there which might get dropped in in the future (if I don’t modify dataflash-logger to have the same capabilities :wink:

You’re in for a great ride ahead, BTW. My only musing on your setup is that APM2.5 won’t give you dataflash logging - the most recent available firmware on it essentially hasn’t been touched in years! You may wish to find a PixHawk-equivalent device of some description (PixHawk1/PixHawk2 (Cube)/PixRacer, that sort of thing). Particularly when it comes to support, you’re more likely to get it with recent hardware than old.

Oh. Use a serial connection between the two; USB is not a great idea (on PixHawk this can cause significant grief).

I get a “permission denied” ssh in as apsync@apsync. I assume that the file has not been fixed in the repo as I just flashed my tx1 and it won’t connect to serial 2. It does connect to APM Planner on UDP as an access point.

RB

Yes Peter, I saw MavProxy normally using 15-20% of the Raspberry CPU. My system is not under pressure at all, so I won’t worry about it for now :wink: . Knowing that cmavnode can handle it is enough for now :slight_smile:

The APM2.5 was given to me by a friend, so I’ll play around with it. I won’t put it in a plane because first day I got it it I fried the voltage regulator :sweat: I fixed it with a replacement, but I’m not risking a plane for this. Will think of what to use when the time comes. WRT using USB comms, it’s simply because I could not find any wiring diagram anywhere and USB worked out of the box (my electronics skills are nearly null… I was amazed I fixed the voltage regulator! :smiley: ). When I get the other controller, I’ll have to rethink all this but it should all be pretty straightforward if I get a good base knowledge with the current system. I may start soon looking at the forums to decide what to buy!!

BTW, yesterday I got video in my GCS using raspivid + netcat which is handled by the raspberry pretty effortlessly and I’m now playing with a few sensors to see what can be done.

BTW, yesterday I got video in my GCS using raspivid + netcat which is
handled by the raspberry pretty effortlessly and I’m now playing with a few
sensors to see what can be done.

Excellent!

Note that there’s a RPi image up on firmware.ardupilot.org in the beta
directory which does video into many of the GCSs out there. Its the only
one of the three boards which supports it ATM ('though TX1 will for the
next release).

If you grab that latest image then you need to open a web browser and go
to http://10.0.1.128:8000 - then hit “Start streaming”.

This works in QGC (Linux and Android), MissionPlanner and Tower.

Ok, I see… you want to keep all the fun for you… Noooo, just kidding! :wink:

Since you move on all this much faster than me and I enjoy all this just a very few hours a week, I’m now focused on getting the telemetry shown in my RoyalPro LCD. I already have an Arduino Nano sending (dummy) data to my receiver’s MSB bus (Multiplex Serial Bus) and I’m about to build the connection between the RasPi and the Nano. This way I can get any MAV value and inject it into my LCD screen on the ground… I always wanted to learn some electronics and this is the coolest way I could ever find!! :heart_eyes:

At some point I’ll come back to the ArduPilot side and learn from all the cool stuff you are building!