Maverick: A dummy wants to give it a try

ok, I guess I’m stuck with the Mavlink proxy

what I’d like to achieve:
I connect a pixracer via its usb to a usb on the RPi3, and try to connect with MissionPlanner via TCP or UDP to the RPi3.

I have checked that the pixracer is on /dev/ttyACM0, using a little py script which just reads and displays the data on this USB. So, in localconf.json I’ve set

"maverick_fc::mavlink_active": true,
"maverick_fc::mavlink_input": "/dev/ttyACM0",
"maverick_fc::mavlink_baud": "115200",

and rebooted. Trying to connect with MP per TCP, it offers me hostname /ip 127.0.01 and port 5760

in the docs it reads as if per default mavlink-router is active, and has an TCP endpoint 5770. Using that did not work. I assume because the ip is wrong, but which ip should I use? I’ve tried my router’s ip but this didn’t work. So I called maverick netinfo which gave me an ip 192.168.2.124, which with 5770 however also didn’t work. Is there any better I can do ???

I wonder if it might not be more convenient to have an AP per default for the first-time setup. This way a user could directly go into Cloud9 to do everything she/he wants/needs without having to do this wifi thing. Along with the next step to do a self update one could tell the user to also do a wifi-setup.

OK couple of things:

  • I assume you know that usb-usb is a bad idea and you know what you’re doing :slight_smile:
  • When you change localconf.json, a reboot doesn’t do anything - it’s not windows :wink: After you change localconf.json, you have to run maverick configure, that will rewrite the mavlink-router config.
  • Have a look at the proxy log to see if it’s connected successfully: maverick log mavlink-router@fc
  • Yes you’re correct, once you get the proxy connected to the flight controller you can then access it from a GCS over tcp using ‘192.168.2.124:5770’ for tcp or ‘192.168.2.125:14573’ using udpci (generally mavlink is easier over udp).

Possibly, yes. The reason it uses normal wifi connection as default is because that’s how almost all embedded/hobby boards do it by default and most people are used to that process. If you provide an AP yes it’s easier to login initially but then it’s isolated from the internet so can’t do an update which is usually the first port of call. If you’re on Mac or Linux then it’s easy because you have zeroconf so can just access maverick-raspberry.local rather than having to find IP. But you’re not the first to suggest this, so will bear it in mind!

MANY THX for your quick reply

usb-usb: ähm … unless you talk about power I then might not know what would be such a bad idea with that. Why?
config: oh, stupid me LOL, thx for the hint
log: thx, that’s useful

:slight_smile:

Apparently if the usb is connected the firmware goes into a kind of ‘ground’ mode and assumes you’re debugging/setting up. Can’t remember exactly what it does, but it’s recommended not to fly with usb plugged in. Use the gpio pins 8 and 10 instead to connect to a telemetry/serial port.

aha, no, wasn’t aware of that
have to investigate this

the whole point is that I’ll need the hw uart for other purposes later on, so it must be usb, otherwise I would have to slam in several usb-ttl adapters, which is really not what I want to do

I do get it connected now … but only very sporadically, not very reliable
the larger problem seems to be that in most cases the mavlink-router terminates early on, both maverick status and maverick log xxx show it’s stopped. From the various experimenting my feeling is that the usb must be connected to the pix at the time when mavlink-router starts up … is that possible that it stops when it doesn’t find the usb connected ??? this would be kind of … well … a bug? Would MAVProxy behave better?

yes, it seems to work only when I have everything powered up and do a sudo reboot, when it appears to always work, otherwise not … hmhmhmhm

EDIT: hmhmhmhm … I have put in a usb-ttl adapter now, connecting to telem1 of the pixracer … and with that the mavlink-router seems to always stop itself … always: “maverick-mavlink-router@fc.service: Main process exited, code=exited, status=1/FAILURE” … not very satisfying
EDIT2: I changed now to mavproxy as proxy, and exactly the same finding, with a USB-TTL adapter the mavlink proxy always terminates itself
EDIT3: which likely is because the usb-ttl adapter is not known as /dev/ttyACM0
EDIT4: which was the cuplrit … it seems to be working now reliably … ufufufuf … I start to feel like a unix geek with all that cmdline hacking

so, with a usb-usb connection the mavproxy somehow doens’t work reliable at all, with a usb-ttl adapter it does
not nice, not elegant, but maybe I have to swallow this …

Yes that’s a problem with the raspberry (and other SBCs). You can get hats with more uarts, or connect a serial controller yourself to the gpio.

That’s odd. mavlink-proxy should retry if the uart disappears (see uartendpoint not working · Issue #67 · mavlink-router/mavlink-router · GitHub, tcpendpoint doesn't retry on lost link · Issue #32 · mavlink-router/mavlink-router · GitHub, Handle HUP on UART · Issue #81 · mavlink-router/mavlink-router · GitHub and others). If the process itself dies, you should either see something in the log (maverick log mavlink-proxy@fc), or if it doesn’t show up in there try looking in the system log (sudo journalctl -xe). Generally mavproxy is much more reliable, but it uses way too much cpu on slower boards like the raspberry. mavlink-router is much more lightweight, also it records flight logs which are automatically processed by the metrics/graphing.
Also make sure to turn BRD_SER1_RTSCTS off if you’re using the telemetry ports and don’t have hardware flow control wired up.

I can help regarding the USB connection. Ardupilot disables a few checks based on whether the USB is connected, as well as sets some connection speed settings. I had to deal with this recently, so here’s my list of things that the USB connection affects:

High priority

EKF health check - does not perform check if USB is connected

Battery failsafe disabled with USB connected

Low priority

Some battery-related arming checks are skipped with USB connected

LED dims with USB connected

Something to do with log download speed and flow control when USB is connected

More Mavlink flow control stuff with USB

Besides these things, flying with USB connected is okay, not counting a proper power supply. My disclaimer is that I fly with a Pixhawk 2.1, which may or may not handle input power differently than the pixracer. You might need to look into how the 'racer selects which input power it uses.

[quote=“fnoop, post:13, topic:24961, full:true”]
You can get hats with more uarts, or connect a serial controller yourself to the gpio.
[/quote]I know … but this I really want to avoid as much as possible … I mean, how ugly is this, and the 4 usbs should be good for something

[quote=“fnoop, post:13, topic:24961, full:true”]
That’s odd. mavlink-proxy should retry if the uart disappears (see https://github.com/intel/mavlink-router/issues/67, https://github.com/intel/mavlink-router/issues/32, https://github.com/intel/mavlink-router/issues/81 and others). If the process itself dies, you should either see something in the log (maverick log mavlink-proxy@fc)[/quote]hm … I may read the signs incorrectly, but from the signs I see this doesn’t appear to work
in maverick status it shows disabled
in maverick log mavlink-proxy@fc it shows “maverick-mavlink-router@fc.service: Main process exited, code=exited, status=1/FAILURE”

I’m going to try with a self-made usb cable, this gives me more control over the power

@Anubis
this is VERY COOL, thank you soo much, this really helps a lot

This Serial to USB issue is unfortunately a reality on most of the flight controllers available, so connecting a RPI to a PixHawk/PixRacer must always go through either the serial pins exposed on the RPI, or plug a bunch of USB2TTL adapters on the RPI.

This gets even uglier on other SBC, like the Odroid’s because the logic level is 1.8v…

I recently found a new PixHawk compatible flight controller that replaced one of the serial ports with a usb port, and this is great - it’s the MindPX v2 that was recently added to our compatible list (ChiBios)

Laughed so hard for the title of this thread…

C’mon @olliw42 :smile::smile::smile::smile::smile:

thx Luis
I guess I have accepted the fact that I need a usb-ttl adapter to communicate with the pix
:slight_smile:

so, having settled this, I went on … just to stumble again

thx to the USB-TTL adapter, connecting to MP per TCP works quite fine now, so I though let’s try to do it with UDP
I couldn’t work this out though, none of the ports listed in the maverick docs worked
I want to mention that when UDP is selected in MissionPlanner, it does NOT ask for an IP, just a port, my knowledge of networking is too poor to understand if this is a problem or not. How to connect to MP per UDP? EDIT: solved, see below

I then decided to boost up the serial communication to 921600 bauds. So, in the localconfig.json I changed to “maverick_fc::mavlink_baud”: “921600”, which works, BUT: when I check what mavlink-router is doing by calling maverick log mavlink-router@fc, when I see that it is first trying out 115200, when 57600, and so on, and only finally tries 921600, and settles for it … HÄÄÄÄ ??? I can’t say I understand this, I mean, I didn’t told mavlink-router to scan the baudrates but specifically told it which one to use … it seems it doesn’t believe users and goes through a list of baudrates, starting at 115200 … anyway

so, I thought, let’s go on further … just to stumble again

I grabbed the vehicle_state.py example from the dronekit folder and simplified it to just the connection part, in order to see if I can get it working. And with connection_string = ‘tcp:192.168.2.124:5770’ it indeed works … cool … BUT: things go astray when I try to also be connected to MissionPlanner. In the maverick docs it is stated “As tcp endpoints can support multiple connections this does not restrict usage.”, from which I thought that this might work, but it doesn’t. Several different issue cases can happen, depending on which connection is established when, and it would be a bit too long to describe that all, but very typically I get a chain of

>>> Exception in message handler for HEARTBEAT
>>> mode 0 not available on mavlink definition

messages, and in some situations

Traceback (most recent call last):
  File "statetest01.py", line 33, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2849, in connect
    vehicle.wait_ready(True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2199, in wait_ready
    timeout)
dronekit.APIException: wait_ready experienced a timeout after 30 seconds.

so, it seems that at leats dronekit isn’t really able to deal with multiple tcp connections.

So I also tried the udp connections, and again, nothing works with them. The result depends on UDP or UDPIN:

Connecting to vehicle on: 192.168.2.124:14570
>>> Link timeout, no heartbeat in last 5 seconds
>>> No heartbeat in 30 seconds, aborting.
Traceback (most recent call last):
  File "statetest01.py", line 34, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2845, in connect
    vehicle.initialize(rate=rate, heartbeat_timeout=heartbeat_timeout)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2117, in initialize
    raise APIException('Timeout in initializing connection.')
dronekit.APIException: Timeout in initializing connection.

Connecting to vehicle on: 192.168.2.124:14573
Traceback (most recent call last):
  File "statetest01.py", line 34, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2835, in connect
    handler = MAVConnection(ip, baud=baud, source_system=source_system, use_native=use_native)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/mavlink.py", line 128, in __init__
    self.master = mavutil.mavlink_connection(ip, baud=baud, source_system=source_system)
  File "/usr/local/lib/python2.7/dist-packages/pymavlink/mavutil.py", line 1242, in mavlink_connection
    return mavudp(device, source_system=source_system, source_component=source_component, input=input, use_native=use_native)
  File "/usr/local/lib/python2.7/dist-packages/pymavlink/mavutil.py", line 880, in __init__
    self.port.bind((a[0], int(a[1])))
  File "/usr/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 98] Address already in use

Again, I lack understanding to understand what all that means.

I think I would like to get UDP working, since I think that talking to specific endpoints provides better means to connect to the vehicle per dronekit. Any suggestion how to get UDP working ???

EDIT: I figured out the UDP connection to MP … one needs to use UDPCI and not UDP in MissionPlanner, and use ports 14573 and above. The problems with connecting both from dronekit and MissionPlanner remain however !, i.e. udp doesn’t work with dronekit and with MP connected per udp and dronekit connected per tcp, things go astray as reported

@fnoop
this Cloud9 editor is really the coolest thing on earth, since it not only gives a good view on the files structure, and has an editor, but especially also because of the terminal … no need to fumble with nasty putty, etc. pp, (and it’s even a very rudimentary ftp). Very cool.

I think that you could advertise this much better in your docs!!! This is exactly what newbs like me need, and want to hear about, and to read that such as thing is there would IMHO be a most attractive attractor.

A statement like “an easy way of exploring and editing files on your companion computer” and similar others really doesn’t do justice to it. At leats, it’s potential wans’t anything clear to me from reading the docs. I don’t know what the proper words would be, but it’s a file browser, editor, and ssh terminal, and the one go-to place for doing all of what is mentioned elsewhere in the docs.

Lol you’re really going for it :laughing:
OK a few notes, firstly on the UDP connection which you eventually worked out, I did post the solution higher up, but should have been more clear:

By default there are 6 UDP ports opened on the proxy, the first three are ‘out’ and the last three are ‘in’. If you’re connecting from an external IP you need to use the last 3 ports and connect with UDPCI. MP UDP connection is only really useful if you’re connecting to a local SITL or if you direct the central proxy to a specific external IP (which is ugly).

When you set "maverick_fc::mavlink_baud": "921600" and then run maverick configure, it uses that value (and others) to transform the various mavlink proxy configurations, held in ~/config/mavlink. If you’re using the default mavlink-router proxy, have a look at ~/config/mavlink/mavlink-router-fc.conf, which has been generated from the values you specify and various defaults. In there you should see ‘Baud=921600,57600,115200,921600’, which is the order it tries to connect, and when it detects a connection it sticks to it. It may be that you set the localconf value but didn’t run maverick configure, in which case it would have been cycling through the default values which are ‘Baud=115200,57600,115200,921600’. It puts the value you specify first of all (921600, or 115200 which is the default), and then a set of fallback values to try (57600,115200,921600).

So, the next bit, dronekit failing. You’re right when you say the maverick docs say ‘As tcp endpoints can support multiple connections this does not restrict usage.’. The tcp proxy endpoint does support multiple connections - you can connect multiple GCSs for example to the same tcp endpoint, as well as dronekit etc. It’s dronekit that face-plants however - since a while back when ardpilot added mavlink routing. Read all about it here: Exception in message handler for HEARTBEAT mode 0 not available on mavlink definition · Issue #677 · dronekit/dronekit-python · GitHub. Basic answer is use something else, like ROS, if you want multiple mavlink devices on the wire. With regards dronekit, mavlink-router and udp, read here ('Normal' udp endpoint doesn't work · Issue #95 · mavlink-router/mavlink-router · GitHub). Dronekit seems to be in maintenance-only mode, no real improvements are being made to it - until (if) droncore becomes available for ardupilot, you might be better looking at ROS/Mavros.

Thanks for the feedback! Will make it more prominent in the docs, as I agree it’s the best interface for those who aren’t as familiar with a terminal. I’ve always had it in mind that a proper web interface will hide all of the config and commands, but just haven’t managed to get round to actually creating it yet :slight_smile:

UDP connection which you eventually worked out, I did post the solution higher up, but should have been more clear:

YEAH, that’s correct … but this crucial bit of info only penetrated my brain afterwards LOL … I acknowledge this, you really did your best, it’s totally and only me who is to blame

“maverick_fc::mavlink_baud”: “921600”

I for sure had executed maverick configure, I’m not making such a mistake twice
the list in ~/config/mavlink/mavlink-router-fc.conf starts howver with 115200, not 921600
so, I just did now maverick configure again, and looked again into ~/config/mavlink/mavlink-router-fc.conf, and it still shows Baud=115200,57600,115200,921600 !!
So, I conclude, and herewith report, that this isn’t doing it as you describe !!
which would explain my observations though

dronekit failing

well, this is now a real downer … and I mean a really real downer … I’m so totally not inclined to use MAVRos
it’s also disturbing to hear that this is a result of ArduPilot’s mavlink routing having changed since 3.3/3.4 … I find similar with the gimbal and camera, in 3.3/3.4 everything (=everything!) was just working perfectly, but with later versions more and more issues crept in making it useless and infunctional, yet the Ardu devs simply claim that there is absolutely no problem (even though it just needs 5 mins of an experiment to see that it goes wrong), and are not doing anything about it … humans ability to deny facts and cherish self-illusion is sometimes shocking
what a downer

not sure, how difficult would you expect would it be to repair this in dronekit?
could maybe a “simple id filter” help? I was wondering anyhow how dronekit would react if there would be two heartbeats on the Mavlink channel, maybe one just could filter out that parts which confuses dronekit … just guessing
how is this actually done in OpenSolo when they run AC3.5? Connecting to MissionPlanner on 10.1.1.10 (=solo)? Or is anyone supposed to connect to 10.1.1.1 (=controller) here?
???

switched to mavproxy, and udp still doesn’t work (of course no other connection to e.g. MP present)

Connecting to vehicle on: 192.168.2.124:14570
>>> Link timeout, no heartbeat in last 5 seconds
>>> No heartbeat in 30 seconds, aborting.
Traceback (most recent call last):
  File "statetest02.py", line 35, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2845, in connect
    vehicle.initialize(rate=rate, heartbeat_timeout=heartbeat_timeout)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2117, in initialize
    raise APIException('Timeout in initializing connection.')
dronekit.APIException: Timeout in initializing connection.

Connecting to vehicle on: 192.168.2.124:14573
>>> Link timeout, no heartbeat in last 5 seconds
>>> No heartbeat in 30 seconds, aborting.
Traceback (most recent call last):
  File "statetest02.py", line 35, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2845, in connect
    vehicle.initialize(rate=rate, heartbeat_timeout=heartbeat_timeout)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/__init__.py", line 2117, in initialize
    raise APIException('Timeout in initializing connection.')
dronekit.APIException: Timeout in initializing connection.

Something’s wrong then - check you don’t have the parameter set somewhere else lower down in the localconf.json - you are setting this in ~/config/maverick/localconf.json right? I’ve just tested it here, it works as expected.

Feel free to head over to https://gitter.im/companioncomputers/migration if you want some more realtime help

There’s no conspiracy - the mavlink routing is a really good thing, it’s just because it creates a network it’s a lot more complex to deal with, and it confuses a lot of clients, including dronekit. It’s been discussed at length for a long time (see Exception in message handler for heartbeat · Issue #610 · dronekit/dronekit-python · GitHub), so I don’t think it will be fixed anytime soon, unless you want to roll your sleeves up and start coding.

14570 is the wrong port - that’s an ‘out’ port. Try 14573.

yes, I understood that, I’m just testing through all combinations, that’s why you also find a result for 14573 :slight_smile: