Maverick: A dummy wants to give it a try


I’m getting interested in using a RPi as companion, and have read up quite a bit, and found some buzz words in the Maverick doc which made me prefer this.

Sadly, I’m really this don’t-know-nothing-about-uinx type of person and have never used RPi or any other unix board before. So, pl be a bit patient with me :).

Simple question: Should I first install the RPi as one usually would (e.g. with NOOBS), and then write the Maverick image on the SD to install Maverick, or is the first step not needed?

I’m a bit confused: To me the SD card looks like the hard drive, and has the OS etc. on it from which the RPi boots, from which I would conclude that with the Maverick image written everything previous becomes irrelevant, on the other hand when starting from NOOBS some adjustments are done such as local time&date etc, and I wonder what happens to this and other things if I would start directly with the Maverick image. (I’m not very eager to pull out a screen and keyboard and mouse to start up, and thus would prefer not having to do this NOOBS thing LOL).


Just copy the image to an SD card, no need for noobs.
You can build/bootstrap Maverick on top of noobs but it’ll take hours/days…
PS, gitter channel for Maverick is

Hey @olliw42 Maverick is designed for people who don’t know or don’t want to know much about unix :slight_smile: . OK, you kind of need to know a bit because the web interface is a little crude and limited at this point (it’s the main focus of the next version), so you have to use the command line to do stuff, but it’s made as simple as possible.

So as @james_pattison says no you don’t need noobs or anything else - you just download the OS image, use something like Etcher to write it to SD card, pop it in your raspberry and turn the power on! If you have an ethernet cable that’s the easiest way to get networking, otherwise you can setup a ‘wpa_supplicant.conf’ file in the /boot partition of the SD card (available from Windows/MacOS/Linux after you flash the card) with your wifi details.

Once (if!) you get it connected, you can just login through ssh or a web browser to ‘maverick-raspberry.local’. If you’re on a windows machine then you can’t do it because for reasons known only to microsoft they refuse to support zeroconf, so you’ll have to find the IP address through your router or some other method.

Maverick controls quite a bit of the basic OS, in order to set everything up for you - it’s designed as ‘plug and play’ system for drones as much as possible, so you can just get on with coding funky stuff. If you want to set local language/timezone, have a look here:

Funny that you call yourself Dummy, after having added uavcan support to the STorM32 gimbal controller, both in software and hardware… :wink:

MANY thx @james_pattison @fnoop

I made good progress

I first did this NOOBS thing, just for curiosity, and then put maverick on the SD.

There had been few little stumbling stones. E.g. I initially was quite confused by these “private property” message, and especially this big red alerts, as it came unexpected. Now having switched from dev to flight things look a bit less red. Since I was logged in I tried the “Run ‘wifi-setup’ to setup wireless networking” but got scared off by the Yn warning that this will overwrite everything, as it came unexpected. So I aborted and tried the “Add wifi configuration to SD card partition” method, but on my SD there is no /boot so I just put the .conf file in the top level directory … and this did not work, at least I could not infer any sign of life. So I went back to “Run ‘wifi-setup’ to setup wireless networking” and this time bravely answered with Y, which indeed allowed me to set the SSID and psk, and completed with Done. And after some time I then could indeed access the web UI, as well as ssh. What does totally confuse me, as I totally don’t understand that, neither our Win PCs nor our Android devices show any wifi for the RPi … yet one can access the web UI and ssh into it … this was, and still is, out of my mind how that is possible and this certainly presented a stumbling stone to me.

I don’t think that the web UI is ugly. Initially I didn’t know what to do with it, but once I realized that this Cloud9 thing also has a terminal to do everything, I really liked it a lot. I mean, how cool is this Cloud9 thing.

So, I think the docu could be slightly more precise in few points (and some printouts be lessened), but overall I must really say that this is quite cool. Really.

I’ve seen that Locale localconf stuff but have not yet figured out how to actually do that. Not that important. This Mavlink proxy stuff is what has my attention next. :slight_smile: (I’m sure I’ll step by with more simple questions ;))

Thx so far, much appreciated,

@ppoirier this unfortunately doesn’t make me know everything, and in the current matter I in fact don’t know nothing (thx to google I now know sudo and proxy and ssh …), so it’s not totally wrong :smiley:


is it possible that the localconf file is NOT in /srv/maverick/software/maverick/conf/localconf.json as stated in the docs, but in /srv/maverick/conf/maverick/localconf.json ?
that’s at least what the hiera.yaml and the content there indicates to me

this Cloud9 thing is super cool :smiley:

@olliw42 yes you may be right :wink: Fixed in master docs, thanks.

Lol, it’s supposed to scare other people off, not you :wink: Glad you got in eventually. Just a couple of things to note:

  • The scary Yn wifi-setup message is only if the blank network settings have already been altered so you shouldn’t get this on a completely fresh install. If you tried this after putting a wpa_supplicant.conf on the sdcard boot partition then it may have picked it up and written the new settings, causing that warning.
  • If the wpa_supplicant.conf that you placed in the boot partition disappears, it means it was picked up and processed. If you didn’t get connected it may be you put the wrong passphrase in, or perhaps it needs a reboot, or some other failure. It doesn’t work in all situations but it does generally.
  • You won’t see a new wifi network show up on other computers, it doesn’t create an AP (access point) by default, but rather connects to whatever AP you specify. It is pretty straight forward to create your own AP if you wish (
  • cloud9 is cool :slight_smile: I can’t take any credit for that of course, it’s a big opensource project now owned by amazon ( When I said ugly, I meant the rest of the Maverick web interface. Which is ugly :slight_smile: (except for MAVCesium and Grafana, they’re cool and nothing to do with me either :wink: .

Have fun :slight_smile:

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, 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 ‘’ for tcp or ‘’ 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


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,, 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,, 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

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

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 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:’ 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 "", line 33, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/", line 2849, in connect
  File "/usr/local/lib/python2.7/dist-packages/dronekit/", line 2199, in wait_ready
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:
>>> Link timeout, no heartbeat in last 5 seconds
>>> No heartbeat in 30 seconds, aborting.
Traceback (most recent call last):
  File "", line 34, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/", line 2845, in connect
    vehicle.initialize(rate=rate, heartbeat_timeout=heartbeat_timeout)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/", line 2117, in initialize
    raise APIException('Timeout in initializing connection.')
dronekit.APIException: Timeout in initializing connection.

Connecting to vehicle on:
Traceback (most recent call last):
  File "", line 34, in <module>
    vehicle = connect(connection_string, wait_ready=True)
  File "/usr/local/lib/python2.7/dist-packages/dronekit/", 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/", 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/", 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/", line 880, in __init__
    self.port.bind((a[0], int(a[1])))
  File "/usr/lib/python2.7/", 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

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.