How use pymavlink

Blue Robotics Software ArduSub
,
21

Ah, ok! that makes sense. It looks like you may have found a bug!

The whole thing hanging is because the rest server runs on it’s own thread and apparently this thread is not being stopped gracefully in some cases.

I just tested here and it takes two presses of ctrl+c to close mavproxy with the server running, but it closes fine. I couldn’t get into a state with only the restserver running.

Is this preventing you from achieving something? Or really just trying to understand what is going on?

1 Like
22

Weird, i spammed ctrl+c and it wouldnt stop, but who knows.

realistically i doubt it will be an issue, it’s not like we’re gonna be force closing mavproxy on the sub while it’s running.

I’m just used to stopping things to conserve resources on the Ubuntu VM and got curious.

23

Hey @williangalvani,

Have you gotten this working on an actual sub?

I ran into trouble getting it to run on the companion and was hoping you could help.

So now I’ll just outline what I did:

  1. used the terminal page on the companion interface to add the server mpdule to mavproxy with pip install mavproxy[server]. It returned this
pi@raspberrypi:~ $ pip install mavproxy[server]                                 
Requirement already satisfied (use --upgrade to upgrade): mavproxy[server] in /u
sr/local/lib/python2.7/dist-packages/MAVProxy-1.6.1-py2.7.egg                   
 Installing extra requirements: 'server'                                       
Requirement already satisfied (use --upgrade to upgrade): pymavlink>=1.1.73 in /
usr/local/lib/python2.7/dist-packages/pymavlink-2.2.4-py2.7-linux-armv7l.egg (fr
om mavproxy[server])                                                            
Requirement already satisfied (use --upgrade to upgrade): pyserial>=3.0 in /usr/
local/lib/python2.7/dist-packages (from mavproxy[server])                       
Requirement already satisfied (use --upgrade to upgrade): future in /usr/local/l
ib/python2.7/dist-packages (from pymavlink>=1.1.73->mavproxy[server])           
Requirement already satisfied (use --upgrade to upgrade): lxml in /usr/local/lib
/python2.7/dist-packages/lxml-3.7.3-py2.7-linux-armv7l.egg (from pymavlink>=1.1.
73->mavproxy[server])                                                           
Cleaning up...

Looks to me like it’s already on there, so i just move on …

  1. Went to git page and checkout a branch that used the updated MAVproxy submodule.

  2. Waited a minute for it to update and confirmed by seeing the version number change when i refreshed

  3. Went to mavProxy page, added restserver to the list of modules to load, and added restserver address 0.0.0.0:5001; to the cmd argument.

  4. Clicked the restart mavproxy button on that page

At this point i could not ping the restserver, nor could i see it when i used netstat -l -a -t -u -p

I tried restarting the entire sub and changing the mavproxy --cmd argument by adding restserver start;

I was still able to connect to the sub and control it normally from the topside computer.
I was even able to use the restserver if i started mavproxy on the topside computer.

So, any idea what the problem might be?
Also, is there a way to access the console of the mavproxy instance that is running on the companion?

Thanks

24

Hi Justin,

I ran into an issue where pip claimed the dependencies where there, but when I tried to run mavproxy and load the server manually it failed because they were not installed.
try pip install mavproxy[server] --upgrade --force-reinstall and see if it helps.

25

Hey @williangalvani,
I got all this working a while ago and it would seem i forgot to confirm that here!

On a different note; however, I’ve noticed an annoyance whilst using the restserver and could not find a solution myself.

So my gripe is that if you start the ROV how we described above (so restserver starts and everything), all the data is not immediately available on the restserver and only appears once a topside mavproxy connection is made (like through QGC). This is mostly an annoyance, but I would really rather eradicate this so that it doesnt cause problems for other members of the project who are less tech oriented.

I have not been able to replicate this with SITL; however, it happens 100% of time on physical rov.

26

Hi @JaylTheGreat,

Do you have a --streamrate option at your /mavproxy?
Something like this should solve your issue.

1 Like
27

I believe one of the the default mavproxy settings on the companion was to set the streamrate to 1 when I forked off.

I will try updating to 10 and see if that fixes the issue.

28

Yup, that worked, thanks!

1 Like