RFC: configurable height for GPS HOME...

[csurf]

Hello, here's my first small effort to contribute...

In working towards my goal of building a stand-alone MW RTH/nav setup w/ CPPM output (for sending to another FC), I'm considering adding a new config option in my setup called 'NAV_HOME_HEIGHT'... The goal of this config option would be to send the craft to a predetermined height when initiating 'GPS HOME' mode.

Here's more/less what I had in mind...

Code: Select all

//config.h
#define NAV_HOME_HEIGHT    1500//height in cm for GPS HOME / RTH

Code: Select all

//multiwii.cpp @ line ~1036
#if GPS
   if (f.GPS_FIX && GPS_numSat >= 5 ) {
      if (rcOptions[BOXGPSHOME]) {  // if both GPS_HOME & GPS_HOLD are checked => GPS_HOME is the priority
         if (!f.GPS_HOME_MODE)  {
            f.GPS_HOME_MODE = 1;
            f.GPS_HOLD_MODE = 0;
            GPSNavReset = 0;
            #if defined (NAV_HOME_HEIGHT)
            f.BARO_MODE = 1;
            AltHold = NAV_HOME_HEIGHT;
            #endif
...
          }

Another feature that I have in mind to go along with this is to prevent GPS navigation until first climbing/descending to the NAV_HOME_HEIGHT (perhaps only for multi-rotors). I was thinking about perhaps a 'GPSNavClimb' flag that prohibits the GPS nav PID factors to be summed into the final PID values until the baro height is within some threshold percentage of the NAV_HOME_HEIGHT value. After that, the flag would be unset and the GPS nav PIDs would be factored in... thoughts on this?

Anyway, I just wanted to throw it out there & perhaps get some feedback on this
(pros/cons, possible improvements, suggestions, advice, etc.)
thanks...

[EOSBandi]

DId you checked MW2.3-navi ? It is already implemented. Code will be migrated to _shared shortly....

[timecop]

But is it a #define? That's the innovative part.
Recompile each time you want to change RTH height.
Fuckin' brilliant.

[EOSBandi]

But is it a #define? That's the innovative part.
Recompile each time you want to change RTH height.
Fuckin' brilliant.

[csurf]

But is it a #define? That's the innovative part.
Recompile each time you want to change RTH height.
Fuckin' brilliant.

@timecop...you're clearly an uptight bastard...
I'm not listening to you, you're a fuckin moron that thinks you're smarter than you really are.

yes, it's a define...as are many, many, many options in MW...
"fuckin' brilliant" that you guys designed the ENTIRE MW codebase this way, just trying to keep with your shitty design.

If you're such a fuckin' genius, then why is the open source project that you're clearly associated with designed in such a messy, disorganized way? Where's your alternative to having to set every goddamn option up as a define??? In another post, I even *requested* having the TRI & HW servo filtering be setup as EEPROM user-configurable options via the GUI, and I was basically told "no, no...that's not the way we do it here...don't rock the boat," so don't start running your mouth as if I'm the idiot that did something wrong. Up until now, my only excuse for ignorance or screwing something up has been that I'm completely new to this piece of shit sketch, but what's yours? After all of your bitching&complaining, I would have thought a brainiac like you would have been able to come up with something waaay better, but you haven't.

'changing the RTH height'....yeah, as if that's something that clearly needs to be changed on-the-fly just prior to or in flight... no more so than, say, the magnetic declination? So if I go on vacation with my quad, I have to recompile, right? Not to mention other options, like, say, ESC calibration? requires re-compilation... Oh, and, hey einstein, why didn't you add this feature in the first place? It's pretty much a standard option in most RTH functions.

It's my 27th post, and I have been looking at the MW code for a few days, and I can already see a bunch of stupid code flaws trapped in a spaghetti-like tangle. The APM code blows this amateur bullshit away... And my intention wasn't to come and bash on MW...I took it on as a hobby and didn't see its crudeness as a problem, except that fuck-heads like you enjoy mouthing off as if you're god's gift to the scene when you're obviously not.

[csurf]

DId you checked MW2.3-navi ? It is already implemented. Code will be migrated to _shared shortly....

ok, wasn't aware of that...thanks...

just checked the code & found this...

Code: Select all

    //Defines the RTH altitude. 0 means keep current alt during RTH (in meters)
   #define RTH_ALTITUDE      0      
    //Wait   to reach RTH alt before start moving to home (0-no, 1-yes)
   #define WAIT_FOR_RTH_ALT   0   

hey timecop, you fuckin' loud-mouth pussy, isn't that exactly what you were running your mouth about? Hard-coding these options up as defines? Now, let's see if you talk shit to EOSBandi for doing the same thing that I had in mind...

[crazyal]

But is it a #define? That's the innovative part.
Recompile each time you want to change RTH height.
Fuckin' brilliant.

@timecop...you're clearly an uptight bastard...
I'm not listening to you, you're a fuckin moron that thinks you're smarter than you really are.

yes, it's a define...as are many, many, many options in MW...
"fuckin' brilliant" that you guys designed the ENTIRE MW codebase this way, just trying to keep with your shitty design.

If you're such a fuckin' genius, then why is the open source project that you're clearly associated with designed in such a messy, disorganized way? Where's your alternative to having to set every goddamn option up as a define??? In another post, I even *requested* having the TRI & HW servo filtering be setup as EEPROM user-configurable options via the GUI, and I was basically told "no, no...that's not the way we do it here...don't rock the boat," so don't start running your mouth as if I'm the idiot that did something wrong. Up until now, my only excuse for ignorance or screwing something up has been that I'm completely new to this piece of shit sketch, but what's yours? After all of your bitching&complaining, I would have thought a brainiac like you would have been able to come up with something waaay better, but you haven't.

'changing the RTH height'....yeah, as if that's something that clearly needs to be changed on-the-fly just prior to or in flight... no more so than, say, the magnetic declination? So if I go on vacation with my quad, I have to recompile, right? Not to mention other options, like, say, ESC calibration? requires re-compilation... Oh, and, hey einstein, why didn't you add this feature in the first place? It's pretty much a standard option in most RTH functions.

It's my 27th post, and I have been looking at the MW code for a few days, and I can already see a bunch of stupid code flaws trapped in a spaghetti-like tangle. The APM code blows this amateur bullshit away... And my intention wasn't to come and bash on MW...I took it on as a hobby and didn't see its crudeness as a problem, except that fuck-heads like you enjoy mouthing off as if you're god's gift to the scene when you're obviously not.

you never heard of baseflight aka multiwii port to 32-bit right ?

[Jimbo385]

This is interesting and actually quite funny!

I wonder if adding profanity to the code makes it work better!

I used to be a COBOL programmer and remember a piece of code that failed that I had to fix. When I opened up the code I immediately noticed lots of words that should not have been there. Evidently the author, long gone, was really pissed off!

Just to add my quid's worth, I'd like to see a default as a #define that can be overridden in the gui.

Can you imagine the laughter at base camp if you hit RTH and it sat there, fell to 1m and tried to return through a fence!

Cheers guys. Please keep up the great work and the playful banter!

[csurf]

you never heard of baseflight aka multiwii port to 32-bit right ?

no, and I really don't care to... why should I?
I was in no way asking a question about/commenting on some other MW port or platform.
it's irrelevant to this post that deals with the original MW on the AVR.

If I knew about or were concerned with that other project (which I'm assuming belongs to timecock, otherwise you wouldn't have mentioned it), I'd be on some other forum/thread, and I wouldn't be here commenting on this...

Is that supposed to be an attempt to come to the defense of timecock? if so, why?
He's an idiot who's clearly been nothing but a rude & offensive piece of shit towards people on this forum for no good reason. It s about time someone called him out for it.

[csurf]

This is interesting and actually quite funny!

I wonder if adding profanity to the code makes it work better!

I used to be a COBOL programmer and remember a piece of code that failed that I had to fix. When I opened up the code I immediately noticed lots of words that should not have been there. Evidently the author, long gone, was really pissed off!

Just to add my quid's worth, I'd like to see a default as a #define that can be overridden in the gui.

Can you imagine the laughter at base camp if you hit RTH and it sat there, fell to 1m and tried to return through a fence!

Cheers guys. Please keep up the great work and the playful banter!

the profanity started with the initial "Fuckin' brilliant" by jean claude van douchebag...

A #define gets replaced with its defined value/statement @ compile time, so it's not really the same as having a runtime variable that can be user-configurable. I don't really understand why you'd set your RTH height to one meter as per your example

[EOSBandi]

DId you checked MW2.3-navi ? It is already implemented. Code will be migrated to _shared shortly....

ok, wasn't aware of that...thanks...

just checked the code & found this...

Code: Select all

    //Defines the RTH altitude. 0 means keep current alt during RTH (in meters)
   #define RTH_ALTITUDE      0      
    //Wait   to reach RTH alt before start moving to home (0-no, 1-yes)
   #define WAIT_FOR_RTH_ALT   0   

hey timecop, you fuckin' loud-mouth pussy, isn't that exactly what you were running your mouth about? Hard-coding these options up as defines? Now, let's see if you talk shit to EOSBandi for doing the same thing that I had in mind...

Khmmmm, these are the defaults, but all of these values are settable via WinGUI...

It is interesting to see how people are react to timecop. His style is questionable at best, but the fact is that he is a fucking genius, and he contributed quite significantly to the community....

[timecop]

the profanity started with the initial "Fuckin' brilliant" by jean claude van douchebag...

it's annoying watching (potentially) clever people pouring resources into dead-end platform with no future.
imagine for a second how much more progress there would be in multiwii if garbage like promini was dropped years ago in favor of arduino mega...

[copterrichie]

It takes time, not everyone is bright nor do they have the resources to just drop old hardware. I was just telling a good friend that I wish I did not invested so much in to the hardware I own and married to MWC because of that, I can't just dump it all for APM or anything else at this time.

[LVNeptune]

@csurf

You clearly are on the wrong forum if you can't deal with timecop. He can be an asshole but if one person is going to ruin your whole day you need to get off the internet. The amount of immaturity in the profane language you keep referencing in your post keeps going higher and higher. It's just making you look like a 12 year old. (Maybe you are 12, I don't know, I don't care). I am not defending either of you just stating an observation.

[Jimbo385]

so going back to the topic of RTH and initial height, the default is 0cm!

So you'd be very unlucky if you needed to initiate this and you were below the treeline!

What about failsafe initiating RTH? So much going on within the NAVI code that I can't remember what's coded for this.

[csurf]

the profanity started with the initial "Fuckin' brilliant" by jean claude van douchebag...

it's annoying watching (potentially) clever people pouring resources into dead-end platform with no future.
imagine for a second how much more progress there would be in multiwii if garbage like promini was dropped years ago in favor of arduino mega...

and it's offensive watching people act in a rude&condescending way towards others for no reason whatsoever...

I agree, ARM/32-bit processors are the future. In fact, before coming here, the main other embedded programming experience I had was with ARM7TDMI processors running ucLinux. Even though it's an older ARM chipset, I could still do all kinds of stuff like running high-priority hardware drivers, spinning off threads, and executing background processes/services. In comparison, switching to the AVR's was like switching from an iPhone to an old Nokia cel phone from 1998, who's highest tech feature was the ability to play the 'snake' game...

the arduino/ATMega platform is basically a 'toy', as are most of the applications it's geared towards. That includes MW, APM, and any other Arduino/AVR-based FC/OSD/Rx/Tx/whatever. Don't hate the player, hate the game; I'm new here, it wasn't my idea, I didn't invent it, I didn't do it, so don't go giving me shit (or anyone else) about it because you personally think that the AVR sucks & MW has no 'future' running on it (don't really even know what that means anyway, seeing as how MW is for RC *toys* and was never meant to be a commercial/professional-grade product).

That said, I didn't buy a 32-bit FC, nor do I have a bunch of STM break-out kits. What I have staring at me is a quad with a KK2, an arduino nano, a sensor breakout, and a GPS. I had an idea on how to milk these components for a better setup to suit my needs, and so I brought it up here on the forum. Then, you immediately started trying to laugh, clown, and be a smart-ass about my efforts, and I only had 20-something posts in!!! It's not as if I was some long-time enemy of yours here on the forum...

I'm not trying to do anything ground-breaking with this setup, nor did I ever claim to be. I was just trying to get into the MW playground and try to contribute. I simply want to make the most of this toy technology in order to get my money's worth. If I wanted something more sophisticated, I probably would have spent thousands on some other gear & I wouldn't even be here in the first place...

remember the golden rule... be cool to others, otherwise expect to get shit tossed back at you...

[csurf]

@csurf

You clearly are on the wrong forum if you can't deal with timecop. He can be an asshole but if one person is going to ruin your whole day you need to get off the internet. The amount of immaturity in the profane language you keep referencing in your post keeps going higher and higher. It's just making you look like a 12 year old. (Maybe you are 12, I don't know, I don't care). I am not defending either of you just stating an observation.

more likely, I'm on the 'wrong' forum because it seems some people here actually seem to condone that guy's behavior.
Trying to pull the 'immaturity' card doesn't apply in this case, when this forum is filled with scattered posts by that dude making comments to people like "you're a fuckin' retard," yet no one had the courage to stand up to him and tell him to shut up. People should expect to receive what they give...I didn't come here to be harsh or disrespectful, but I also don't have to follow your rules of so-called internet etiquette when some random guy in Japan is mouthing off and trying to be a bully.

BTW, who said anything about him having ruined my whole day? I have no problem going off on some random internet idiot in under a page's worth of words & still go on with my day as if nothing ever happened (don't know about you, but I do know how to type quickly and multi-task)...

[csurf]

so going back to the topic of RTH and initial height, the default is 0cm!

So you'd be very unlucky if you needed to initiate this and you were below the treeline!

What about failsafe initiating RTH? So much going on within the NAVI code that I can't remember what's coded for this.

The code comments say that the default of 0 means that the craft should hold its current altitude & not necessarily drop down to 0cm.

Failsafe mode in MW is apparently different...
It's only meant to slow down & land the craft (only for multi's?), so it's not directly linked to RTH.

The weird thing with MW's RTH is that you have to manually enable all of the required flight modes for RTH (ANGLE/HORIZON, BARO, MAG if you want it to steer head-first back home). You'd think that, by simply enabling GPS HOME mode, that all of these would be enabled automatically, but it doesn't appear to work that way.

Another issue that I've thought about is the following: if you setup your radio/receiver to enable 'GPS HOME' upon detecting a failsafe, then there might be an abrupt transition from 'GPS HOME' mode to whatever mode you had prior to going into failsafe as soon as the Rx re-binds to the Tx. For example, if you were in ACRO before the failsafe kicked in, you'd either have to be ready to 'catch' the transition back into manual control, or set your radio's AUX channel(s) to stay in GPS_HOME mode so that there's a seemless transition when the Rx reconnects to the Tx. If you're in an area with intermittent signal loss/re-sync, then it might get messy. Perhaps it would be cool to have an option where, once GPS_HOME has been initiated, you'd forcefully have to switch it off (via another AUX channel combo) once you're actually ready to take back manual control. Just a thought...

I have another thread about it, but my idea was to setup the MW as a dedicated RTH module (even though some people are laughing/criticizing it).

In my opinion, the *best* RTH solution would be one where the craft tries to backtrack & follow the exact same flight path (both in terms of direction & height) that it took prior to having the RTH initiated. As far as I know, I don't think any other RTH does this (not even the APM). Taking a multirotor as an example, if you flew under/around obstacles (buildings, trees, a hill, etc.) before hitting the RTH failsafe, then it would be crucial for the multi to stop & go back home exactly the same way it came. This would require establishing a waypoint history for the track, something that would be easily do-able on the MEGA boards, don't know if the smaller 328's could handle it (doubt it), unless a ton of other code was stripped out.

With my project, I had the idea that I'd eventually start stripping out a bunch of extra stuff that wouldn't be needed for RTH...It would only support either Rx pass-thru or RTH and nothing more...

[copterrichie]

Memory is the issue with the 328 and always have been. IMO, that is why there are so many #define statements.

[Jimbo385]

I believe in keeping things simple or as simple as possible.

The key to all of these parameters is not just understanding what they do but also what their limitations are. It is impossible to cater for every eventuality. I'm sure that if asked to define a list of all the scenarios where RTH could/would be initiated, it would be lengthy. yes with some overlap but lengthy none the less.

Let's keep the code simple with what we have already and maybe start a wishlist and see where we go from there.That way we can a stable base that can be built on. I think that's what's happening now.

[copterrichie]

With my project, I had the idea that I'd eventually start stripping out a bunch of extra stuff that wouldn't be needed for RTH...It would only support either Rx pass-thru or RTH and nothing more...

If motor pins are not required, that would free up the SPI port. With that free, and External eeprom board and even a SD card is a possibility.

[csurf]

I believe in keeping things simple or as simple as possible.

The key to all of these parameters is not just understanding what they do but also what their limitations are. It is impossible to cater for every eventuality. I'm sure that if asked to define a list of all the scenarios where RTH could/would be initiated, it would be lengthy. yes with some overlap but lengthy none the less.

Let's keep the code simple with what we have already and maybe start a wishlist and see where we go from there.That way we can a stable base that can be built on. I think that's what's happening now.

It get's a little tough to keep it simple when it comes to RTH, but I agree simpler is better...
Another 'contingency' that's not currently taken into account is "what happens when there's a loss of GPS lock during an RTH/GPS_MODE flight?" The current code doesn't appear to handle that scenario; it simply falls through to BARO mode. Ideally, I guess you'd either try to loiter/move around in a big circle (trying to get a fix), or simply land, both of which could be catastrophic based on the situation). You could probably get more sophisticated, like try to climb vertically to try to get a fix, or backtrack, but then you starting getting into really crazy territory of having some super complicated auto-pilot logic. At the very least, it should try to land. Currently, it'll simply fall through the GPS test code and stay in BARO indefinitely unless it manages to get a GPS lock. If not, it might just sit there, drifting & burning battery. In the case of a plane, it'll probably just throttle and keep flying away (don't even think BARO currently works in airplane mode since it doesn't appear to implement the elevator)

[csurf]

With my project, I had the idea that I'd eventually start stripping out a bunch of extra stuff that wouldn't be needed for RTH...It would only support either Rx pass-thru or RTH and nothing more...

If motor pins are not required, that would free up the SPI port. With that free, and External eeprom board and even a SD card is a possibility.

That's a great/cool idea...
no, they wouldn't be required if it's only PPM sum out that's required...
(guessing this might not work if you need four separate PWM channel outputs for AIL/ELE/THR/RUD)