Traceback (most recent call last):
File "/usr/local/bin/mavproxy.py", line 4, in <module>
__import__('pkg_resources').run_script('MAVProxy==1.6.1', 'mavproxy.py')
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 534, in run_script
self.require(requires)[0].run_script(script_name, ns)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1445, in run_script
exec(script_code, namespace, namespace)
File "/usr/local/lib/python2.7/dist-packages/MAVProxy-1.6.1-py2.7.egg/EGG-INFO/scripts/mavproxy.py", line 972, in <module>
File "/home/pi/.local/lib/python2.7/site-packages/pymavlink-2.3.7-py2.7-linux-armv7l.egg/pymavlink/mavutil.py", line 110, in <module>
set_dialect(os.environ['MAVLINK_DIALECT'])
File "/home/pi/.local/lib/python2.7/site-packages/pymavlink-2.3.7-py2.7-linux-armv7l.egg/pymavlink/mavutil.py", line 102, in set_dialect
mod = __import__(modname)
ImportError: No module named v20.ardupilotmega
everything in pymavlink/dialects/v10 and pymavlink/dialects/v20 look fine.
I haven’t personally created custom MAVLink messages before, but from a read of ArduPilot’s Adding a New MAVLink Message docs my main thoughts/ideas are
Does it work to send and/or receive your custom message with plain Pymavlink, or even just import Pymavlink and receive some arbitrary messages from your vehicle?
Are you sure your message definition(s) use valid xml (e.g. is pymavlink able to build the ardupilotmega.py file successfully)?
Is it worth trying to update / re-install mavproxy?
Have you tried creating a mavproxy module, like discussed near the bottom of those docs?
If none of those are helpful I’d recommend asking for further advice from the general ArduPilot folks (via their forum or their discord), since they’re the primary Pymavlink and MAVProxy developers
I appreciate the reply but my stuff works on other machines. I have a development virtual machine that has no problem. Everything worked just fine on our previous Pi before we went to blue OS on the companion.
Aha, I wasn’t aware you were using BlueOS on your onboard computer because the post was tagged as Companion (which I’ve now adjusted).
I’ll ask the software team if they have particular ideas, but it’s worth noting that
BlueOS does not use mavproxy (it uses mavlink-router), which may cause some resource fighting if you’re trying to use mavproxy at the same time
The containerised nature of BlueOS means that installations you make in the main container (without using red-pill to operate on the pi itself, if you’re using the web terminal) will not be persistent across boots / container restarts
Where pymavlink is used in BlueOS it’s using Python 3.9, so there may be additional strangeness going on if it’s also been installed for Python 2.7 (although that would generally be an issue with pymavlink’s convenience scripts overwriting each other, rather than when using the library directly).
So we can better understand (and potentially try to reproduce) your situation, can you specify
I’ll make sure I get the right tag from now on, sorry for the miscommunication. In dialects/v20 there is no __init__.py. I would think that this would be created automatically since the entire tree below ~/.local/lib/python2.7/site-packages is created by python setup.py install --user.
I created an empty __init__.py and it works.
Two other installations did not have this problem.
uname -a shows Linux raspberrypi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7i GNU/Linux
The page at 192.168.2.2:2770 says Companion Version 0.0.31
I was using a terminal from 192.168.2.2:8088 but installed VNC and a desktop because I wanted to run emacs and other apps.
I don’t understand.
192.168.2.2:2770/system shows mavproxy as an active service. ps -ef | grep mav doesn’t show mavlink-routerd running.
For future reference, where are the docs for mavlink-routerd? Also, any pointers to Docker info (and red-pill?) as it applies to BlueOS?
Mahalo for taking the time to try to help me @EliotBR
Does this mean you managed to resolve your issue, and what remains is just confusion as to why that solution was necessary?
Haha, ok, you are in fact using our previous “Companion software” then (which is no longer being developed), not the new BlueOS. I’ve changed the topic back, and the points in my previous comment do not apply.
I’m not sure if there are any outside of the README of the repository. From a quick look, the upstream repository does seem to have a more extensive README, but I’m unsure whether the additions are documentation of functionality that is present in both, or documentation of new features that are not currently in the repository BlueOS is using.
I believe we’re currently looking at changing to something else, because we’re wanting better performance and some additional features than it provides, even though it’s already quite a bit more performant (and less CPU-heavy) than mavproxy.
We do not yet have introductory developer documentation for BlueOS, which is partly because we’re in the process of creating an extensions system that will mean most external development will be in separate containers rather than BlueOS core. You can learn about docker itself on the official website, but we will also be making some high level overview documentation about how docker and containerisation are related to and used in BlueOS, as well as some example extensions.
red-pill is a shell script in BlueOS that allows a terminal user to drop from inside the core docker container into the underlying operating system, which is the home of persistent file storage (for logs and the like), and lower level functionality (enabling features like restarting the core container without having to restart the Raspberry Pi itself).
The name is a reference to The Matrix, where the main character can choose to take a blue pill to stay in the controlled dream land of the matrix (our core Docker container), or take the red pill to be pulled out of the matrix and get to see the real world for what it is.
