-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: ability to add python modules to extend functionality #56
Comments
Interesting idea; unfortunately, as an ex-FORTRAN programmer, I have a severe pathological aversion to languages that are dependent on significant white space which I'm unlikely to be able to overcome, even with medical or psychological help. However, mwp already provides a dbus instance; extending that to provide the information that an antenna tracker needs is a really interesting idea. Consider me interested, as it would be language / application independent.
(for example). |
i know what you mean, but i'm trying to force myself to learn python. (i prefer perl). as far as what's needed, yea, home position (or theoretically would be armed position), current location and height, and you can work out range bearing from the two known gps coords - again another python module i've made :D |
perhaps 10 years ago, this Anyway, I'll extend the dbus implementation to provide a (flight) status, home / armed location and current location / altitude. Seems like an interesting project (for both of us). |
cool.... yea i was the same way... way back when yahoo messenger was a thing, i used to help maintain a ruby chat program. worked through 5 revisions of the protocol (got to the point they changed it every 6 months) until they finally pulled the pin on messenger. that was all written in ruby. been a while since i wrote in ruby. used to all the time. maybe i might figure it out again. |
OK, so I propose to add a few new dbus methods, synchronous call to get the home and vehicle location, and async (dbus signals) to push event by event changes to home or vehicle locations. The mwp dbus API introspection will then return (something like):
And there will be
And example output via a simulator that generates fake home every 60s and fake vehicle every 5s:
Expect a test branch in github in the next few days. A client application can either poll for location changes or subscribe to the async signals. Will this meet the requirement ? |
dang dude.... that was quick lol. i've just been reading up on dbus signals etc (which im assuming is what you mean by events). but yea all you need really is lat/long/alt for the home and the aircraft, you can figure out the rest relaively simple |
And here's the naive python example:
|
dayum.... |
i would suggest (and i assume you're doing it) would be to force send a "home changed" and "Location Changed" event on arming, as I can for see a situation where it has a location for the uav, but not a home location on startup. if that makes sense |
The signals will be pushed whenever the data changes and on vehicle state changes (including arm). I either need to have a vehicle state changed signal, or include it in the other signals .... |
I would suggest a separate one to.be honest. Juat then you're not tying yourself in to having to potentially make changes to the format in the future id you tie them into the location data string. |
Sure, makes the implementation easier too. |
There's now an initial implementation in
Then replay a log file (Blackbox or mwp log) in the mwp instance. You should see a stream of status / location / sat coverage signals displayed in the second terminal. Note that
There's also a less capable python example. None of this is final, so any suggestions for improvement are welcome. |
cool... im working on nit now... you wouldnt happen to have a logfile i can replay by chance? |
Attached a zip file with a mwp (not blackbox) log and the output captured from it by |
thanks..... btw
|
As Dbus is not a high volume interface, I've added a position update rate limit property. This is not a problem for real world telemetry protocols, however for pre-arm, USB / MSP polling, mwp can potentially generate a lot of Dbus traffic. There is now a Dbus property 'DBusPosInterval' to (optionally) rate limit position updates. Value is the minimum update interval in 0.1s units; 0 disables rate limiting, the default is 1 (10Hz), a value of 10 would give a 1Hz positional update rate. Ruby and Python examples updated. |
Here's three more useful logs culled from public sources (RCG, Github) issues that will be more representative for a longer range antenna tracker: http://www.zen35309.zen.co.uk/bbl/lr-logs.tar.xz |
yea tbh, i think 10hz is more than enough for updates. I went out today and the dbus interface seemed to work great. I havent finished the actual servo control yet, but it kinda works. i have to figure out how to get the bearing normalised into -90/90. which is what the controller takes. plus i havent yet finished building the hardware yet - it's still running through the cnc :) |
LTM at best is 5Hz, so I might drop the default to that. Don't want to wear out your servos. |
I think 5 times/s is adequate. You're not doing 200mph in small circles after all :) |
I think it works :D now to make it pretty 👍 and see if i can get the servos to move right :D
|
Nice |
do you have a list of what the status numbers are (i assume 1 is armed) |
There's a DBus API for that (from the ruby sample, 0 indexed).
Anything non-zero is armed. |
@stronnag slinks off to write some documentation .... |
I'm supposed to be working too lol... |
and following from the previous example, display *man-readable states:
|
AFAIK, the ruby example exercises the whole API. I know it's not python but .... |
that's fine, i got it |
how would I access the bearing the MWP is using in the mwp-dbus.vala file to include it in the signal but im a little confused as to where they're actually would be getting set so I could get the correct (class?) variables i was thinking of adding something like:
to the top and then changing the loc signal:
|
im' trying to figure out why mine is way off compared to yours |
I'll add them ... tomorrow, need to get up stupidly early in the morning to get Mrs Stronnag on her train for the Chelsea Flower Show. |
OK, new commit and new methods / signals:
And similar Get* methods. The *Polar method /signal report:
I think this alone might be enough to drive a tracker? |
shouldn't the direction and azimuth have "out" before them in the definition or am i reading it wrong as i'm getting an error when i call GetPolarCoordinates - tried that even in d-feet
mwp_dbus.vala line 82
|
Damn it, yes. I'm fixing it. I'll write a test this time. |
yup... modified mine to include the out now it seems like it's working :D check velocity too :D |
done |
It's the reciprocal (+/- minor latency). The default implementation follows the MSP COMP_GPS message which provides the range and bearing from the vehicle to the ground station (which always struck me as useless: I'm at the ground station and I want to know where the vehicle is! (and the direction to walk if I crash it at range). The Flight View widget and speech is output is controlled by:
If you use Bing Maps for better zoom (or the other BB logs posted above) you'll see the affect. |
This issue / pull request has been automatically marked as stale because it has not had any activity in 30 days. The resources of the mwp team are limited, and inactive issues/PR are a burden on the project. |
Nice, very very neat. |
@stronnag ty. beauty is, it'll work with anything that can send a particular packet format.... plain text CSV 🍭 |
@stronnag another update for you. it seems to work good (dbus side) only thing i've noted is that the bearing seems to be 180 out as noted in #62 and i was trying to figure out what units it was sending some things out in as velocity wasn't what it showed - figured out it was m/s :D but it all seems good. only need to get some other things like arming state added _ (in another request) https://www.youtube.com/watch?v=WT5rb5nPlEo (ignore the audio. it's way out of sync - gg YT) |
This issue / pull request has been automatically marked as stale because it has not had any activity in 30 days. The resources of the mwp team are limited, and inactive issues/PR are a burden on the project. |
Automatically closing as inactive. |
not sure if it's at all possible, but would it be possible to add functionality to extend it with python modules. i've written a maestro servo controller module (same as using in ardupilot) in python so would be cool to be able to use that as an antenna tracker module.
The text was updated successfully, but these errors were encountered: