Replies to This Discussion

DeveloperPermalink Reply by Michael Oborne on July 24, 2012 at 3:54pm

how would the device talk to the planner?

tcp?

other?

• ▶ Reply

Permalink Reply by Ray K on July 24, 2012 at 5:54pm

UDP actually.

TouchOSC transmits and receives data with a host pc over local network (wifi) using the Open Sound Control protocol. The Processing sketch opens a udp socket and talks to the iTouch, then outputs data to a terminal.

• ▶ Reply

DeveloperPermalink Reply by Michael Oborne on July 25, 2012 at 6:10pm

technicly that should be possible.
using python to create a udp listner, and sending rc override commands to the ap. which the Mission planner python interface supports

• ▶ Reply

Permalink Reply by Ray K on July 25, 2012 at 6:56pm

I thought about doing that.  So, this would be just added on to the end of whatever Script is already in there?  

And, is there any other documentation on doing this besides my link in the original post?

Thanks Michael.

• ▶ Reply

Permalink Reply by Thomas Hays on September 18, 2012 at 12:24pm

I'm also interested in using the python script.  I've found the proper button on the "actions" tab.  but when i click I'm only presented with a text file showing the example code.  When I close that window it asks if I want to execute (I say yes) and it will execute the example, but locks my rc controller out.  I also never see any of the displayed text.......  I'll keep workin.

• ▶ Reply

Permalink Reply by Thomas Hays on September 19, 2012 at 8:53pm

to restore RC functionality I simple send Script.SendRC(7,1500,True)    <-  This sends 1500 us signal to channel 7 (which i have nothing on) and frees up my other control channels.  This tactic works fine as a single code line...... but so far fails when included as part of a script.  

those wishing for a nice iron python tutorial.... I found this:http://www.voidspace.org.uk/ironpython/winforms/index.shtml

• ▶ Reply

Permalink Reply by Paul Ferragut on September 24, 2012 at 10:34am

Would be an interesting way to use drone! did you had any success with trying this technique?

• ▶ Reply

Permalink Reply by Ray K on September 24, 2012 at 5:54pm

Time has been an issue.  I've also realized that the Mission Planner is a much better version than anything I could create.  I'm hoping to start building my drone by December, and after that's all running, maybe I will return to this idea.  Meanwhile, I'm content with the joystick and autonomous waypoint options available to us.  Keep in mind that using a joystick is already slow, because of chain of communication (Joystick --> USB --> Mission Planner --> USB --> XBee/ 3DR ground radio --> drone radio --> ArduPilot).  Imagine adding a router/ adhoc network to that mix and having to wait for the UDP traffic to be routed.  This all results in a noticable delay that can become a safety hazard.

Also, this would require me to learn Python, which again I do not have time for at the moment.  However, I would be happy to collaborate with anyone who has time and experience working on this.  

• ▶ Reply

Permalink Reply by Alexis Dray on April 14, 2013 at 1:19pm

Hello all, well I'm about to do this as well.

Has anyone made progress here? 

• ▶ Reply

Permalink Reply by Alexis Dray on April 14, 2013 at 2:05pm

sorry, that was a bit vague. What i mean is, I would like to create a 

virtual' interface system which where input is 'independent' i.e. some generic device is sending commands via UDP as Michael explained, where python is initializing the UDP listener.

My specific goal would be sending commands via web interface, perhaps driven by nodejs (?)

Without needing hand holding, does anyone have a general next steps idea, as in how to go about setting up python to listen in 'realtime'? 

• ▶ Reply

Permalink Reply by Austin Suhler on April 17, 2013 at 10:11am

Allow me to give you something I made. It's a simple UDP setup that receives values from the planner, but you could easily turn it around to send values. Be careful though, I have noticed some float-precision problems, that I believe is within the mission planner's python interface itself, where you lose 2-3 points of precision, something I have yet to completely trace back to the source. This causes a problem with GPS points more than anything. resulting in you losing about 300-1000ft of accuracy on any values you return. I'm not sure if this occurs sending values in, but I know it happens pulling values out. My forum post is here: http://www.diydrones.com/forum/topics/apm-adaptive-flying-video-ana...

My files are on the bottom, but you might want to go to the third page and check out more options found on the bottom post, and read my code comments which I forgot to add in the actual code ;) I literally have never used Python before this, and it is incredibly easy to use. I recommend using Python 2.7, not 3 or higher, because it is easier and has a lot more example code and support. Also, you might benefit from using TCP instead of UDP. Let me know if you have any questions! Thanks!

• ▶ Reply