pymavlink usage on Raspberry Pi

Dear all,

I was hoping someone with some experience with pymavlink could help me out.

I currently have a Raspberry Pi connected to my Pixhawk via the telem2 port and have developed an image processing program to track a target. So far, I am able to use MAVPorxy to connect to the Pixhawk via the command-line and send commands like arm, set params etc. but I can't seem to set up a connection within my python script using pymavlink (The goal is to override channel 4 to provide lateral tracking).

I think it may be something to do with how I have installed pymavlink. I simply cloned the repository to my home directory and ran "sudo setup.py install". Any light that could be shed would be great.

Thanks.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

          • Yes, it would mean adding a micro; thus my question in relation to the tracking he was doing on the Pi. Did I mention I was talking about low frequency drift? The processing speed could be as low as 10 Hz. Yes, it would involve some programming which is why I was asking about how his was working before we started to code ourselves. 

            Low frequency would involve playing with Integral (I) gains, not Proportional (P) gains.

  • It seemed pretty straightforward to get my Pixhawk recognized in my python script using pymavlink. Can you paste your code and the error message you're getting?  Similar to the other comments in this thread, after you install pymavlink, you should just need to include "from pymalink import mavutil" and then call the connection create function "mavutil.mavlink_connection(.....)" with the appropriate arguments. 

    Side note, what are the pros/cons of using the telem2 port versus the USB connection to connect with the Pi?  

    • Do you know the commands needed to get the drone to go to a set of GPS coordinates, without interfering with waypoints already entered?  I'd like to set the mode back to auto and have the drone continue on its path.

      Python script would be great.

      Right now, I'm just using "Loiter" and changing the radius to +- to turn, and "Cruise" to go straight...

      Can't control altitude that easily.  Seems like there should be a simpler way.

      Just to demo what I'm trying to do, check this out:
      http://droneatc.ca/

      If you don't see two drones flying around (you may have to zoom in) then I've quit running my simulations.  Just ping me at the email on the info page if you want to see the demo.

      • will the final system have a single controller which knows the position of every UAV? if it were to detect a collision before it happened, how would the system prevent it? Will it also be able to control these UAVs in emergencies?

        • That's the idea.  Right now, I have 2+ simulated drones reporting in to a central server, and that server can send MAVLink messages and alter the headings of the drones connected to it.

          My algorithms need work though.  It's been a while since I did this type of math.

  • Please don't give up on this!

    The ability to deploy a multirotor from the roof of an armoured vehicle and have it return to land on the exact same roof (perhaps even if it has moved) would greatly enhance the utility value in the military setting...

    Debussing to place a multi on the ground in the midst of the unfriendly is not a desirable task; Furthermore thick bush often makes take-off and landing near impossible.

    • I won't give up, but this is for civilian use.  Military have their own solutions.  I trust you've heard of the switchblade?

      http://www.wired.com/2011/10/tiny-kamikaze-drone/

      If I had military funding, I'd be done this already.

      • Watch out with those Rpis. Specially if it's a 2

        http://www.neowin.net/news/a-camera-flash-will-make-the-raspberry-p...

        • Developer
          Specifically, Only the RPi2*, with a very bright XENON flash. A link to a better quality article http://www.theguardian.com/technology/2015/feb/09/raspberry-pi-2-ca...

          And it interrupts only the power supply circuit. If you use the NAVIO+ autopilot add on the power circuit is redundant, the chip would also be covered by the daughter board offering some protection, but putting bluetack/sugru/tape completely fixes it. Unlike the issues with light sensitivity and the baro sensor.

          "Watch out those RPis" general type comment would infer you have a vested interest in an alternative, oh you do! ;-) which is great BTW.

          *the guardian article explains no Pi is effected other than the RPi2
          • This post spoke about an RPi connected to a PixHawk @Bill but hey! great that you brought Linux autopilots ;). 

            You'd get surprised of how supportive I am towards NAVIO when compared to other autopilots. They share my vision and push forward this community to accept Linux-based boards. They just announced support for the Odroid C1 so I'm pretty sure that they've got their backs covered ;).

            In any case, great hearing you already thought of a solution.

            P.D.: This video makes me doubt of the veracity of that "better quality" article.

This reply was deleted.

Activity