LinkStateThread

[John Wiseman]

Pat, I was looking at LinkStateThread in mavelous.py to figure out if it needs to be a separate thread (I was a little concerned about the un-threadsafe access to the packet statistics counters).

It looks like those communication stats on packet loss and packets sent/received are only updated when messages come in and when they go out.  We already get called when messages come in.  We could add a small hook to mavproxy to notify modules when messages go out, or a hook to mavproxy's periodic_tasks function that would let any module be called periodically.  Both seem generally useful--do you have any thoughts?

(Also, I keep feeling the temptation to fork and cleanup mavproxy, but that would be madness--right?)

John

[Pat Hickey]

John,

These both sound like good ideas, as do the rest of the email traffic I've seen in the last day or two. Unfortunately I'm home in New Jersey pulling the insides out of my parents house for the next week so I won't be able to check it out, but as always I trust your judgment.

Best

Pat

--
 
 

[Craig J. Elder]

Pat

Did your folks have some damage from the storm?

Craig

--
 
 

[Chris Gough]

Hi John,

> (Also, I keep feeling the temptation to fork and cleanup mavproxy, but that
> would be madness--right?)

I've had a couple of conversations with Tridge about possible MavProxy
refactors, and he basically said "yeah I should do that, maybe after
<some more important thing>". Last time, he actually said
incorporating some work you had done would be his first step.

Instead of a big fork, why not start cateloging ideas using the github
issue system, discuss them, and submit patches. There is a small but
real community of active MavProxy module developers, who could
probably contribute ideas and help implement the changes too.

It's not clear to me how module development should relate to MavProxy
development over the longer term. Perhaps one day the module
development process will be decoupled from MavProxy development
process. A module distribution system + "live" module management
features in MavProxy. Until then, I think forking might be
counterproductive.

Chris Gough

> John
>
> --
>
>



--
.

[John Wiseman]

On Thu, Nov 8, 2012 at 5:48 PM, Chris Gough <christoph...@gmail.com> wrote:

Instead of a big fork, why not start cateloging ideas using the github
issue system, discuss them, and submit patches. There is a small but
real community of active MavProxy module developers, who could
probably contribute ideas and help implement the changes too.

I've been opening issues and submitting code for both mavlink and mavproxy, it's just been a long time since anyone has responded.  Which is totally reasonable--sounds like they've been busy with the outback challenge, etc.  But I don't want mavelous development to go that slowly.   mavlink has had a bug in the message-to-json code for several months (https://github.com/mavlink/mavlink/issues/65) which forces us to fork that for mavelous, and really mavelous is already a fork of mavproxy though I haven't kept track of whether that's still strictly necessary for any reason other than the module packaging structure.

 

It's not clear to me how module development should relate to MavProxy
development over the longer term. Perhaps one day the module
development process will be decoupled from MavProxy development
process. A module distribution system + "live" module management
features in MavProxy.

Decoupling module development from mavproxy is a goal of mine, and I've been trying to lay the groundwork for that (for example https://github.com/tridge/MAVProxy/pull/7).  I think it would make developers' lives a little easier, and probably end up making things easier for users, too.

John

[overlordsc]

I dont know if this needs a new topic or not, but is mavelous currently sending a heartbeat to the plane/copter? I am wanting to setup failsafe on telemetry but don't see where a heartbeat is configured.. Thanks.