Cellular Solo

Hitting a snag today. Struggling to get the mavlink messages from the solo on udp port 14550 to forward over the zerotier vpn network to mission planner running on a PC. Don't really understand where in the solo's config it is set what interface this happens over (have looked in sololink.conf and can't really see the answer)... I tried a range of iptables combinations forwarding in both directions - but couldn't get it working yet.

I won't give up - but could really use some suggestions on how to forward the mavlink (and other udp ports that the solo uses over a different interface, and to a different ip range)...
 
Have you played around with any of the config files? You're gonna need to change some settings in sololink.conf at the very least. Probably also hostapdconfig.py .... probably some others. The assumption that you'll be using the built-in WiFi and that Artoo will be the AP is pretty ingrained in the sololink coding....
 
I will try to install mavproxy on the solo...
Tried to install mavproxy on the solo... Long story short - it didn't work. I did get python pip installed. Also learnt that the original smart package repository used no longer has a working source of rpms. I have looked at the config files - no easy way to forward the mavlink udp messages over another interface, without breaking the default wifi link between artoo and the solo (which I don't want to do - I want to have wifi when in range, and then 4G when out of range). My thoughts are now along the lines of:
1. Further trial and error with iptables to see if I can forward the right ports, in the right way.
2. Trying a ISO Layer 2 bridge approach (which still can be done over a zerotier vpn) - such that the wifi and 4G zt networks would be bridged together and act as one. This involves recompiling a new kernels for both artoo and the solo to include bridging models, and cross compiling (or finding a suitable binary of the brctl tools)
3. Writing a very simple python port 'reflector' - to listen for mavlink udp messages, and repeat them over the zt 4G network..
I don't think this is going to be quick or easy to solve....
 
  • Like
Reactions: Wetstone
I'm thinking that approach # 3 is going to be most fruitful.

Take a look at telem_control.py in /sololink/net/usr/bin/ . Might be a useful starting point since it already sets up some ports.....
 
Another small step forward... Today I have:

- Modified my artoo controller - based on the info here: Solo Controller (Artoo) AT11A - Schematics / Pinouts So I now have a controller with:
  • A usb host connection (testing and working with 4G dongle)
  • A usb device (via the OTG pins) so that I can plug the Artoo into a PC and have it act as a storage device, an ethernet device, serial device etc. (but I haven't tested the gadget drivers yet, but I assume it will work)
  • A debug (serial via a FTDI cable) serial port - into Uart0 (which has a console / terminal into the Artoo's IMX (very useful to have this and not need to use SSH, especially when messing about with the network config)
- I rebuilt the kernel on the artoo to add the cdc_ether USB driver (to work with the 4G dongle), plus also enable network bridging. I can post photos / details of how I added the devices (as could be used for a range of USB accessories + applications).

Next steps are to:
- Recompile the solo kernel (again) to add the network (Layer 2) bridging module.
- Add the zerotier vpn client to the artoo (to connect over the internet to the solo)
- Try different iptables / routing combinations to try to get traffic working between solo <----> artoo <----> solex & misson planner (at Layer 3).
- If that doesn't work - try Layer 2 bridging (to combine the wifi and zerotier networks)...

It's the network / routing config that I'm finding the hardest - as this is not my area of expertise...I also don't want to stop the solo working normally over wifi (ideally want to be able to switch between them whilst in flight)..

1588593206899.jpeg
 
Last edited:
  • Like
Reactions: just_bruce
Another small step forward... Today I have:

- Modified my artoo controller - based on the info here: Solo Controller (Artoo) AT11A - Schematics / Pinouts So I now have a controller with:
  • A usb host connection (testing and working with 4G dongle)
  • A usb device (via the OTG pins) so that I can plug the Artoo into a PC and have it act as a storage device, an ethernet device, serial device etc. (but I haven't tested the gadget drivers yet, but I assume it will work)
  • A debug (serial via a FTDI cable) serial port - into Uart0 (which has a console / terminal into the Artoo's IMX (very useful to have this and not need to use SSH, especially when messing about with the network config)
- I rebuilt the kernel on the artoo to add the cdc_ether USB driver (to work with the 4G dongle), plus also enable network bridging. I can post photos / details of how I added the devices (as could be used for a range of USB accessories + applications).

Next steps are to:
- Recompile the solo kernel (again) to add the network (Layer 2) bridging module.
- Add the zerotier vpn client to the artoo (to connect over the internet to the solo)
- Try different iptables / routing combinations to try to get traffic working between solo <----> artoo <----> solex & misson planner (at Layer 3).
- If that doesn't work - try Layer 2 bridging (to combine the wifi and zerotier networks)...

It's the network / routing config that I'm finding the hardest - as this is not my area of expertise...I also don't want to stop the solo working normally over wifi (ideally want to be able to switch between them whilst in flight)..

View attachment 11126
If you wouldn't mind posting the details of how you added the devices [maybe in a separate post?] I would certainly appreciate it. You're doing yeoman's work my friend....
 
If you wouldn't mind posting the details of how you added the devices [maybe in a separate post?] I would certainly appreciate it. You're doing yeoman's work my friend....
Sure - do you mean from a hardware perspective, or software - or both? Then there's info here for the artoo usb connection.. Solo Controller (Artoo) AT11A - Schematics / Pinouts

I will write up the software side when I can.
 
  • Like
Reactions: just_bruce
I'm greedy - I meant both. Though the software side is probably the most important, I'd think.

In case I haven't said it, thank you for pursuing this work so determinedly.
 
  • Like
Reactions: Professorpip
Some success I think... So far I have been able to:
- Link the solo and artoo controller over a 4G / zerotier connection. Things like the gimbal angle controls work, and the controller display has the right telemetry, battery readings etc.
- Get telemetry from solo <--- over 4G ---> to artoo controller <--- over wifi ---> to Mission Planner (on PC) - i.e. mavlink works.
- Get live gopro video & telemetry from solo <--- over 4G ---> artoo controller <--- over wifi ---> to QGroundcontrol (on PC). The video is really good - latency about the same as wifi.
- I can disable the wifi between the solo and artoo controller - and the connection keeps working (over the 4G vpn) , and can see the traffic over the 4G link (i.e. it really is working over the 4G, not the wifi).

- How I did this:
1. As previously mentioned I have 2x Huawei 4G usb dongles - one connected to the solo accessory port, and other to the imx6 board in artoo.
2. I took some of the approach from the uavpal (Parrot Disco and Bebop2) 4G mods, to get the USB dongles working and connected to a zerotier vpn. (as I've outlined in previous posts)
3. I rebuild the artoo and solo's kernel to enable tun, and the cdc_ether usb device (which is how the USB 4G dongles appear to the linux kernel).
4. I modified & recompiled the telem_forward.cpp on the artoo to not reject packets from any IP address (it will just accept them no matter what - which seems to help keep the link up)
5. After trying a number of iptables, proxy arp, and briding ideas (none of which I could get to work), I tried to simply assign the vpn interfaces the same IPs that solo and artoo normally have (Solo = 10.1.1.10, artoo = 10.1.1.1)... I did't expect this to work as normally to don't want 2 interfaces with the same IP address. But amazingly I could then change the IP addresses of the wifi interface of the solo to something random e.g. 10.2.3.4 (or anything), and magically the connection would say up - the linux kernel would automatically just start routing the traffic over the 4g vpn link instead.
6. Having a serial debug console into artoo is vital - it means you can bork the wifi connection to artoo, and still get in to see what's happening and fix it. Eventually it should be possible to write a script eliminate need for the serial console.

What I haven't got working yet is solex... Unlike the PC, although it would still connect to the artoo AP, and get a sensible IP address, it wouldn't connect with telemetry or video. For now that's a nice to have - as I can for now use Qgroundcontrol on a Laptop PC and still get the same telem / map info and telemetry.

I've not actually flown this yet and with the virus lockdown it's hard to when I will properly. I may be able to do a test in the back garden over the weekend, but for now I'm limited to tests 'on the bench'.

Next steps are to:
- I might be able to fix solex if I change the wifi settings as per here 3DR Solo Dev Guide/Dronekit Python on Ubuntu 14.04 - Robotics Computation - NPS Wiki
- The same approach may mean I don't require the usb dongle at the artoo, rather I could possibly tether the artoo to a mobile phone (like the uavpal mod does)
- I need to write this up fully, and post my code modifications somewhere -once I've got it settled in my mind what were the key steps that seemed to be critical.
 
Very very cool. I now wanna dig around in the networking code and see what is up - as some of the things you've been able to do I didn't think you should be able to, and some of the things you aren't I thought you should be able to....

Sigh. I never have enough time when I wanna have enough time.....
 
  • Like
Reactions: Professorpip
Oh -
My -
Lordy!

Well done, my son - very, VERY, well done indeed!

It really is a thrill, to actively watch someone crack-each-nut along the way and hit that first, "I did it - I DID IT!", moment.

Keep going, PLEASE, keep going!

- Kick each of the remaining niggles to the curb,
- Resolve the entire 'pathway to success' into readily, easy to follow steps,
- Take yor time to shift the resulting workflow into a document, ( one that is carefully considered and detailed enough to permit those 'below you' to also attempt with a reasonable level of confidence... )
- Sit back and enjoy the adulation!

Nevertheless and without question, simply a stunning and superb achievement!

My hat sir, is well and truly off!
 
Progress for today was:

- Got the solo controller (artoo) and my tablet (running Solex, Qgroundcontrol, and / or Mission Maker for arduilot) connected and working via USB - with the android device replacing the 4G dongle (it was in usb tether mode). This makes the network config easier, as I can do what I like to the wifi link between the solo and artoo, and it won't affect the link between artoo and the tablet.-

- As the other day got the solo and artoo to communicate via a 4g VPN (zerotier link)... and am able to get this going repeatedly.

- I need to look deeper into the source code for why the solo changes mode when I do an ifconfig wlan0 down (i.e. to turn the wifi off completely) - I think something is monitoring wpa-supplicant, or hostapd, or the dhcp client (or something) that in normal flight would happen if the solo flew out of range, and thus RTH would automatically be initiated... This is a very sensible behaviour - but I need to inhibit this as when I'm connected via 4g I don't want a loss of wifi to trigger a RTH necessarily. I would only want a RTH to be triggered when both the Wifi and 4G link were down, so need to understand it and perhaps change how it determines the status of the link.
 
pixrc.cpp appears to be checking the IP address that RC command packets are coming from [line 337-344 in sololink/flightcode/pixrc/ ]......there is also failsafe activation code about. I wonder if somehow it appears your command packets from zerotier are coming in over the 10.x.x.x address...and when you take that down the IP address disappearing puts it into failsafe?
 
  • Like
Reactions: Professorpip
pixrc.cpp appears to be checking the IP address that RC command packets are coming from [line 337-344 in sololink/flightcode/pixrc/ ]......there is also failsafe activation code about. I wonder if somehow it appears your command packets from zerotier are coming in over the 10.x.x.x address...and when you take that down the IP address disappearing puts it into failsafe?
Could be... Certainly worth having a closer look....
 
This is awesome Professorpip! Looks like you have made some fantastic progress. Would love to be able to take my E3372 4G modem from my Disco, and plug into my Solo to fly. The Disco 4G softmod that Marc built really is brilliant, and it sounds like you almost have the same solution dialed in on a 3DR Solo. Let me know when you are ready for someone to test it out, and I'd be glad to try and set it up on my Solo. (very familiar with the Disco 4G softmod)
 
  • Like
Reactions: Professorpip
This is awesome Professorpip! Looks like you have made some fantastic progress. Would love to be able to take my E3372 4G modem from my Disco, and plug into my Solo to fly. The Disco 4G softmod that Marc built really is brilliant, and it sounds like you almost have the same solution dialed in on a 3DR Solo. Let me know when you are ready for someone to test it out, and I'd be glad to try and set it up on my Solo. (very familiar with the Disco 4G softmod)

Hi.. I think I'm getting there. Work and life stuff means I've not been able to do anything with my solo for a few weeks. But I will try to upload the custom firmware image and some notes somewhere in case anyone wants to try. I should point out this is no where near as polished as the Disco softmod...
 
  • Like
Reactions: Arny58
This has been a super-interesting thread. Great work profpip! I have been thinking about a project that involves building opensolo outside of vagrant as well, and your work may have spurred me on. Thanks!
 
  • Like
Reactions: Professorpip

Members online

No members online now.

Forum statistics

Threads
13,093
Messages
147,741
Members
16,047
Latest member
pvt solo