Maverick: A dummy wants to give it a try

APSync / Companion Computers
21

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.

22

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:

23

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

24

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.
25

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.

26

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

27

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

28

[quote=“fnoop, post:25, topic:24961, full:true”]
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?[/quote]yes, I fool around with just this one
that’s how it looks like

// These are local config settings.  Because they can include sensitive information like usernames and passwords, this file
//  is excluded from ever being committed back to git.
//
// Any manifest parameter can be added here, what follows is a sampling of common useful settings.
// More info and settings can be found here:
// https://fnoop.github.io/maverick/#/modules/intro
{
	// Set passwords
	// "base::users::mav_password": "", // Set mav user encrypted password here (obtain using: mkpasswd  -m sha-512 -s)
	// "base::users::root_password": "", // Set root user encrypted password here (obtain as above)
	
	// Set defaults for wifi.  If set, any wifi interface detected will be automatically activated with these settings.
	// These setting can be overridden in the per-interface settings.
	"wifi_ssid":    "EasyBox-929660",
	// "wifi_passtype": 	"wpa2",
	// "wifi_passphrase":	false, // unencrypted wifi passphrase, strongly recommended to use psk below instead
	"wifi_psk":    "Iwonttellyou", // must be encrypted psk created using 'wpa_passphrase MySSID MyPassphrase'

	// See https://fnoop.github.io/maverick/#/modules-network for more info
	// Note a fallback generic eth0 and wlan0 config is always created in addition to these settings
	"maverick_network::interfaces": {
        	"wman0": {
        	    "type":	"wireless",
        	    "macaddress": "b8:27:eb:94:38:2d", // put your wifi mac address here, can be obtained from 'maverick netinfo'
        	    "ssid":    "EasyBox-929660",
        	    "psk":    "Iwontttellyou" // must be encrypted psk created using 'wpa_passphrase MySSID MyPassphrase'
        	}
	},

	// "maverick_desktop::enable": true, // Desktop is disabled by default

	// Flight Controller (fc) mavlink setup
	// "maverick_fc::mavlink_proxy": "mavproxy", // Default mavlink proxy type to use
	// "maverick_fc::mavlink_active": false, // Whether the mavlink proxy is active or not
	// "maverick_fc::mavlink_input": "/dev/ttyS1", // Input source for mavlink proxy, how the Companion Computer connects to the Flight Controller
	// "maverick_fc::mavlink_baud": "115200", // Input baud rate for UART connections
	"maverick_fc::mavlink_proxy": "mavproxy",
//	"maverick_fc::mavlink_proxy": "mavlink-router",
	"maverick_fc::mavlink_active": true,
//	"maverick_fc::mavlink_input": "/dev/ttyACM0",
	"maverick_fc::mavlink_input": "/dev/ttyUSB0",
	"maverick_fc::mavlink_baud": "921600", //"115200",
//"maverick_hardware::raspberry::overpower_usb": true,
	// "maverick_fc::rosmaster_active": false, // Whether ROS master for fc is active or not
	// "maverick_fc::mavros_active": false, // Whether Mavros for fc is active or not - requires fc rosmaster to be active
	// Dev SITL mavlink setup - note this requires dev environment to be active
	// "maverick_dev::sitl::mavlink_proxy": "mavlink-router", // Default mavlink proxy type to use
	// "maverick_dev::sitl::sitl_active": true, // Whether SITL is active or not
	// "maverick_dev::sitl::mavlink_active": true, // Whether mavlink proxy is active or not
	// "maverick_dev::sitl::rosmaster_active": false, // Whether ROS master for sitl is active or not
	// "maverick_dev::sitl::mavros_active": false, // Whether Mavros for sitl is active or not - requires sitl rosmaster to be active
	
	// "maverick_dev::ardupilot::armeabi_packages": false, // Set to true to install packages that allow px4 firmware to be compiled and uploaded to fc
	// "maverick_vision::visiond::active": false, // Whether visiond is active or not
	// "maverick_vision::vision_landing::active": false, // Whether vision_landing is active or not
	
	// Add classes here
	"classes":
	[
		// "maverick_network" // CAUTION: Read what this does before enabling: https://fnoop.github.io/maverick/#/modules-network
	]
	
}
29

Hmm, sure the proxy itself is receiving and sending OK? You can also use localhost and the out ports as you’re on the same system as the proxy, so localhost:14570. I’m actually wondering if dronekit supports udpci, possibly not.

30

I’m not the conspiration type of guy, I though do uphold experimental facts :wink:

some progress on the connect-dronekit-plus-MissionPlanner front, I do get much better behavior with mavproxy instead of mavlink-router
for dronekit I tried two connections
(A) ‘tcp:192.168.2.124:5771’
(B) 'tcp:192.168.2.124:5770’
for MissionPlanner I tried three connections
(1) ‘udpci:192.168.2.124:14574’
(2) ‘tcp:192.168.2.124:5770’

the three combinations A-1, A-2, and B-1 work fine, in as much as I do not get these “Exception in message handler for HEARTBEAT” messages, and connection works independent on which comes first
the combinations B-2 does NOT work however, when I have MP connected and then try to connect dronekit I get the “Link timeout, no heartbeat in last 5 seconds” error, when I have dronekit connected and then try MP it doesn’t connect
that’s kind of funny given that a tcp should be able to handle two connections LOL

anyway, with the other combinations I guess I can live, I only get some false messages when I have dronekit connected and then connect MP, which do not appear to be harmful though

I definitely would have thought that this basics would just work after so many years of companion computers … not maverick’s fault, certainly not, but …

31

[quote=“fnoop, post:29, topic:24961, full:true”]
Hmm, sure the proxy itself is receiving and sending OK? You can also use localhost and the out ports as you’re on the same system as the proxy, so localhost:14570. I’m actually wondering if dronekit supports udpci, possibly not.
[/quote]no, I’m not sure about anything
my only knowledge is what I have learned in the above so far :slight_smile:
I’m in this mode of trying combinations and observing what happens, without any deeper insight

32

Really weird, I’ve just cut and paste that and it works fine for me, just as it always has. Can you see Device=/dev/ttyUSB0 in your ~/config/mavlink/mavlink-router-fc.conf? If you change the baud to say 921601 and rerun maverick configure, do you at least see the config files being regenerated?

33

I agree. It’s been quite frustrating at times working around bugs and finding simple things that should work but don’t. A large part of the problem is a lack of community interest, momentum and cooperation around ‘companion’ computers (terrible term). Seems a lot of people reinvent a lot of wheels but there’s been no real progress for a long time. I would say the closest anyone got to really interesting work was the Solo with the smartshots - that was really cool use of an onboard computer - but it took way too long to opensource the code and is very specific to the hardware environment it lives in so hasn’t made it outside yet.
One of the goals of Maverick is to hopefully allow people to quickly get over the initial hurdle of setting up the underlying system, so they can get on with doing cool coding, functions or logic like with the solo smartshots. The fact it’s taken this long for you to get a simple dronekit connection going shows there’s still work to be done.

34

[quote=“fnoop, post:32, topic:24961, full:true”]
Can you see Device=/dev/ttyUSB0 in your ~/config/mavlink/mavlink-router-fc.conf?
[/quote]yes
and you know what’s weird, I do now see also Baud=921600,57600,115200,921600 (I for sure have done plenty of maverick configure and sudo reboot and power-ups before, before reporting a result !!!)
I only can assume that this is so now since I have switched to mavproxy …
I’ll try to reproduce this, give me some 10 minutes

EDIT: ok, I cannot reproduce my earlier observations in this matter … I did maverick configure and reboots so often that it’s not clear to me how that could not have come through, but I consistently must have done something differently than what I’m doing now without realizing it … so, I guess I should surrender and agree that maverick is working fantastically :slightly_smiling_face:
sorry for the having created this confusion

35

I’ve tried some more udp-ish things with mavlink-router and dronekit
’localhost:14570’, ‘localhost:145734’, ‘localhost:14574’,
‘127.0.0.1:14570’, ‘127.0.0.1:14573’, ‘127.0.0.1:14574’,
none works
I guess I’ll settle with tcp::5771 and mavproxy, was the best so far

36

@olliw42
Going to try to retrace your steps with a rpi2+maverick and the newer ChiBios versions :slight_smile:

37

great !

this is the modified dronekit example .py file I was using

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
© Copyright 2015-2016, 3D Robotics.
vehicle_state.py: 

Demonstrates how to get and set vehicle state and parameter information, 
and how to observe vehicle attribute (state) changes.

Full documentation is provided at http://python.dronekit.io/examples/vehicle_state.html
"""
from __future__ import print_function
from dronekit import connect, VehicleMode
import time

connection_string = 'tcp:192.168.2.124:5771'
#connection_string = 'localhost:14574'
#connection_string = '127.0.0.1:14573'
#connection_string = '192.168.2.124:14570'
#connection_string = '/dev/ttyUSB0'

# Connect to the Vehicle. 
#   Set `wait_ready=True` to ensure default attributes are populated before `connect()` returns.
print("\nConnecting to vehicle on: %s" % connection_string)
vehicle = connect(connection_string, wait_ready=True, source_system=199)

vehicle.wait_ready('autopilot_version')

# Get all vehicle attributes (state)
print("\nGet all vehicle attribute values:")
print(" Autopilot Firmware version: %s" % vehicle.version)
print("   Major version number: %s" % vehicle.version.major)
print("   Minor version number: %s" % vehicle.version.minor)
print("   Patch version number: %s" % vehicle.version.patch)
print("   Release type: %s" % vehicle.version.release_type())
print("   Release version: %s" % vehicle.version.release_version())
print("   Stable release?: %s" % vehicle.version.is_stable())

print(" Global Location: %s" % vehicle.location.global_frame)
print(" Global Location (relative altitude): %s" % vehicle.location.global_relative_frame)
print(" Local Location: %s" % vehicle.location.local_frame)
print(" Attitude: %s" % vehicle.attitude)
print(" Velocity: %s" % vehicle.velocity)
print(" GPS: %s" % vehicle.gps_0)
print(" Gimbal status: %s" % vehicle.gimbal)
print(" Battery: %s" % vehicle.battery)
print(" EKF OK?: %s" % vehicle.ekf_ok)
print(" Last Heartbeat: %s" % vehicle.last_heartbeat)
print(" Rangefinder: %s" % vehicle.rangefinder)
print(" Rangefinder distance: %s" % vehicle.rangefinder.distance)
print(" Rangefinder voltage: %s" % vehicle.rangefinder.voltage)
print(" Heading: %s" % vehicle.heading)
print(" Is Armable?: %s" % vehicle.is_armable)
print(" System status: %s" % vehicle.system_status.state)
print(" Groundspeed: %s" % vehicle.groundspeed)    # settable
print(" Airspeed: %s" % vehicle.airspeed)    # settable
print(" Mode: %s" % vehicle.mode.name)    # settable
print(" Armed: %s" % vehicle.armed)    # settable

while(1):
    print( vehicle.attitude )
    time.sleep(1)

#Close vehicle object before exiting script
print("\nClose vehicle object")
vehicle.close()

print("Completed")
38

now let’s make it a step more complicated

I’m using mavproxy, the pix is on USB0 via a usb-ttl serial adapter, and dronekit connects to tcp::5771

now I’d like to connect with a PC running MissionPlanner connected to another USB port, that is the proxy should handle two serial/USB ports now :smiley:
(in a real life application this would be e.g. a 3DR telemetry)

I think I have read that mavlink-router cannot handle more than one USB, I looked a bit into the git for MAVProxy, and it seems to me it could handle several USB ports, I don’t know though how to configure that in maverick
suggestions?

39

@olliw42

Please avoid using the usb port. IMHO it’s easier to just have 3 simple wires from a serial port on the flight controller to the rpi pins

regarding the RPI USB ports, I’ll make you a question. What happens when you connect a USB port from one computer to a USB port on other computer ?

edit: this http://www.linux-usb.org/gadget/ doesn’t solve the problem but provides an alternative to use the usb ports on the rpi in a different way

40

[quote=“luisvale, post:39, topic:24961, full:true”]I’ll make you a question. What happens when you connect a USB port from one computer to a USB port on other computer ?[/quote]for all devices I deal with they will happily communicate with each other … might be different in unix land :wink:



isn’t avahi-daemon (whatever this is) preinstalled with maverick?

I can’t see I’m asking for the impossible