Thread Tools
This thread is privately moderated by JohnET, who may elect to delete unwanted replies.
Apr 04, 2017, 11:24 AM
because rust never sleeps....
HugoRogers's Avatar
Quote:
Originally Posted by evensis
Stall sensing feature.....


Now i'm wondering, since you've implemented the close loop system for air speed control you're more or less halfway there already, and would be a bolt on. If the Vector knows the stall speed of the airframe, then the closed loop system can auto increase motor speed to compensate for the condition. A dumbed down version of this feature, would be the models operator doing the tests themselves, and manually inputting the stall speed of the airframe via the GUI or the OSD GUI, and the Vector prohibiting air speed from dropping down this low. Again, pitot tube only feature as GPS ground speed would not give the necessary data for this.

First one obviously being the most difficult to implement, with the secondary being substantially easier.
Sounds really neat. My only concern would be handling failure conditions. We already know that there is a problem if the airspeed system passes before flight tests, but then fails *during* flight. It would not be difficult to imagine a situation where the software is trying to deal with what it thinks is a stall situation by giving max throttle permanently. This might cause some consequences.
Sign up now
to remove ads between posts
Apr 05, 2017, 03:59 AM
That 'IC' guy
evensis's Avatar
Quote:
Originally Posted by HugoRogers
Sounds really neat. My only concern would be handling failure conditions. We already know that there is a problem if the airspeed system passes before flight tests, but then fails *during* flight. It would not be difficult to imagine a situation where the software is trying to deal with what it thinks is a stall situation by giving max throttle permanently. This might cause some consequences.
True, while max throttle isn't the end of the world in some cases, it could be disastrous if one is running a particularly fine tuned mission accounting for certain mah/km and runs out of battery miles from home. Certainly onscreen warnings of the stall would be helpful here for manual intervention. However, do we know what form of failure conditions happen with the pitot tube sensor? I touch wood haven't had it do anything odd on my 3 models I have it installed on so far! Now, in theory, we can account for a pitot tube sensor blockage quite easily with the following:

if pitotSpeed == 0 AND altitude > 0 AND GPS groundspeed > 0
THEN
disable stall sensing function.

Vector can see us moving along at a certain pace via GPS, but pitot tube is saying 0, definately something wrong there! We could further monitor the altitude, so that if its within a 10 feet tolerance over 5 seconds (or indeed the vector is not seeing us dropping out of the sky over the course of half a second), then we can be absolutely sure we are not stalling and in fact something is wrong with the pitot tube.

From this, we can ascertain that a GPS lock would be required in order to compensate for failure conditions. So we'd have a further failure condition of:

if GPS satellites == 0
THEN
disable stall sensing feature.

My only concern is if the pitot tube sensor has a hardware failure (i.e throwing off spurious values), this would be significantly harder and in fact probably nigh impossible to account for, but the least likely (I would hope ET Team!!!) to occur. Although, we could have a max speed setting for the airframe, which would sort of account for a hardware failure if it starts throwing really out of the realm values. Something that could be done, is using the summary max speed results and using that to insert max speeds settings. I.e Vector detects WOT for say 10 seconds, artificial horizon is level (such as using 2d with hold) and ascertain max speed from that. Similarly, a max speed setting could be entered manually via the GUI. I could see this setting being helpful in more than just a stall condition however, the setting could be added to prevent nuking ones battery accidentally if they've jogged the throttle stick while in level flight without realising it (I know ive done it) so that the Vector throttles it down while throwing an alarm to the screen after so many seconds.

Obviously the Vector would need to know about a power plant change however! This is a halfway house for a hardware failure and certainly not an absolute solution, hardware failures are notoriously difficult to account for (as to why Windows will chuck blue screens and reboot your PC when hardware cocks up).

Would be pretty interesting to get this feature in, I've nearly soiled my pants before while flying along and all of a sudden a wing has dropped and i'm thinking arghh, has a servo gone? Nope, just stalled it!!
Last edited by evensis; Apr 05, 2017 at 04:22 AM.
Apr 05, 2017, 04:23 AM
because rust never sleeps....
HugoRogers's Avatar
Quote:
Originally Posted by evensis
True, while max throttle isn't the end of the world in some cases, it could be disastrous if one is running a particularly fine tuned mission accounting for certain mah/km and runs out of battery miles from home. Certainly onscreen warnings of the stall would be helpful here for manual intervention. However, do we know what form of failure conditions happen with the pitot tube sensor? I touch wood haven't had it do anything odd on my 3 models I have it installed on so far! Now, in theory, we can account for a pitot tube sensor blockage quite easily with the following:

if pitotSpeed == 0 AND altitude > 0 AND GPS groundspeed > 0
THEN
disable stall sensing function.
I think the problem here is that if a problem happens during flight (and I agree, the chances of this are slim) then you will probably not get 0 airspeed. I have flown with a partly blocked pitot and it was overreading by about 100%. Which is interesting, because that would not cause a max throttle demand, that would presumably cause a demand for less throttle... which would likely lead to a stall... how ironic :-)

The fact is that ET are not yet comfortable with detecting airspeed failures during flight (hence the limitations with the closed loop implementation at the moment), so much so that that system does not even allow for fallback to GPS in the case of a detected failure (whatever that means) during flight.

Really interesting stuff though!
Apr 05, 2017, 06:16 AM
That 'IC' guy
evensis's Avatar
Quote:
Originally Posted by HugoRogers
I think the problem here is that if a problem happens during flight (and I agree, the chances of this are slim) then you will probably not get 0 airspeed. I have flown with a partly blocked pitot and it was overreading by about 100%. Which is interesting, because that would not cause a max throttle demand, that would presumably cause a demand for less throttle... which would likely lead to a stall... how ironic :-)

The fact is that ET are not yet comfortable with detecting airspeed failures during flight (hence the limitations with the closed loop implementation at the moment), so much so that that system does not even allow for fallback to GPS in the case of a detected failure (whatever that means) during flight.

Really interesting stuff though!
That's pretty interesting, I would have thought the opposite would have happened with a partially blocked pitot! Although I have forgot one huge point from this discussion that all stalls have in common, is as the plane tries to keep its altitude the angle of attack increases. Vector can only detect the pitch which wouldn't be sufficient.

I've just been doing some research on how full scales work out stall conditions, and the big commercials (Airbus/Boeing) use vanes on the side of the fuselage to measure the AoA, while Cessna's and the like use a form of pitot tube on the leading edge, that when a stall condition occurs and air flow is hugely disrupted over the wing, the negative pressure of that air is blown into a cockpit horn warning of the stall.

I think the second method is the most useful for our models, but probably requires absolute positioning within the leading edge which may make things tricky. I would imagine a pitot tube would pick up the disruption in the air around the wing in a stall event (and comparing it against a secondary pitot, where if 1 is dramatically less than the other for example).

Seems ArduPilot are currently working on stall detection, seems quite a tricky subject (although they are also endeavoring to get it to work without an airspeed sensor, that seems super tricky). But based on what i've read the gyros are able to pick up a stall, but needs additional data to accurately determine it. They seem to be looking at a differential pressure sensor for AoA data along with vane sensors, but based on comments seem prohibitively expensive. Perhaps with ET's suppliers they maybe able to get something out at a reasonable cost. I'd be certaining shouting 'shut up and take my money' if they bought this out.

We can wish
Last edited by evensis; Apr 05, 2017 at 06:26 AM.
Apr 05, 2017, 06:32 AM
because rust never sleeps....
HugoRogers's Avatar
Quote:
Originally Posted by evensis
That's pretty interesting, I would have thought the opposite would have happened with a partially blocked pitot!
Possible that that is an error case, but with a slighly crimped and kinked pitot pipe, flying in constant wind conditions I saw a rise from around 25mph to over 45mph.

It probably depends whether it is the static pressure, or the pitot pressure circuit which is restricted as to whether the reading increases or decreases ?
Apr 05, 2017, 06:36 AM
That 'IC' guy
evensis's Avatar
Quote:
Originally Posted by HugoRogers
Possible that that is an error case, but with a slighly crimped and kinked tube, flying in constant wind conditions I saw a rise from around 25mph to over 45mph.

It probably depends whether it is the static pressure, or the pitot pressure circuit which is restricted as to whether the reading increases or decreases ?
I would imagine thats the case, I wonder if the conditions are separate enough to make a logical distinction in code. I know when I cover the static sensor with my finger it always raises to a flat 9mph (or 15mph?? its one or the other) and never moves from that. By the sounds of things based on your observations, it appears that the pitot pressure circruit problem may be the more painful one to figure out.
Apr 17, 2017, 05:01 AM
Registered User
wazoo22's Avatar

Graupner's SUMD digital format


Is there a way to make the Vector and MicroVector compatible with Graupner's SUMD digital output? I'm told that most of the digital formats are very similar, except for SBUS, and their weird signal inversion.
I like my Graupner, and would like to use SUMD with my four Vector/MicroVectors.
Apr 17, 2017, 05:41 AM
@ET,
please include an 'at least' option for RTH altitude which will allow user to configure a minimum RTH altitude.

Example:
If aircraft is lower than the min RTH altitude, climb to it. If the aircraft is already at or above the min RTH altitude, simply fly home at the current altitude.

(note that this is different from mountain mode, which adds an offset to the current altitude at the point in time when RTH is enabled)
Apr 19, 2017, 03:36 AM
Registered User
wojciechwas's Avatar
Quote:
Originally Posted by changosurf
@ET,
please include an 'at least' option for RTH altitude which will allow user to configure a minimum RTH altitude.

Example:
If aircraft is lower than the min RTH altitude, climb to it. If the aircraft is already at or above the min RTH altitude, simply fly home at the current altitude.

(note that this is different from mountain mode, which adds an offset to the current altitude at the point in time when RTH is enabled)
I second that! I think this would be way more useful than the mountain mode for a fixed wing.
Apr 19, 2017, 12:48 PM
Registered User
Hope I am not reading on the wrong page but ..
It seems to me that is exactly what it is explained on vector beta 12.60 Safety/Nav Setup TAB and using the NORMAL Home RTH Altitude Mode.
It climb or descend then fly home and close to home descend to Home Altitude and circle.
Seems to be like you ask.
Apr 19, 2017, 03:42 PM
Quote:
Originally Posted by zemanel
Hope I am not reading on the wrong page but ..
It seems to me that is exactly what it is explained on vector beta 12.60 Safety/Nav Setup TAB and using the NORMAL Home RTH Altitude Mode.
It climb or descend then fly home and close to home descend to Home Altitude and circle.
Seems to be like you ask.
no, this is not what we're asking for.
'normal' RTH mode will always fly home at RTH altitude.
If the plane is higher than RTH altitude, it will descend to RTH altitude, which might cause problems if you've been forced to fly higher in order to avoid an obstacle.

What we're asking for is a 'minimum height' setting, that will only climb to RTH height (if below it), and ignore it if the plane is already higher than the minimum height.

example:
- 'minimum RTH height' setting is 50 meters.
- if plane is flying at 30 meters when RTH is enabled, the plane will climb to 50 meters and return home
- if plane is flying at 100 meters when RTH is enabled, then the plane will simply fly home while maintaining its altitude at 100 meters
Apr 21, 2017, 09:27 PM
Master of Disaster!
Sweetieinsf's Avatar
Quote:
Originally Posted by changosurf
no, this is not what we're asking for.
'normal' RTH mode will always fly home at RTH altitude.
If the plane is higher than RTH altitude, it will descend to RTH altitude, which might cause problems if you've been forced to fly higher in order to avoid an obstacle.

What we're asking for is a 'minimum height' setting, that will only climb to RTH height (if below it), and ignore it if the plane is already higher than the minimum height.

example:
- 'minimum RTH height' setting is 50 meters.
- if plane is flying at 30 meters when RTH is enabled, the plane will climb to 50 meters and return home
- if plane is flying at 100 meters when RTH is enabled, then the plane will simply fly home while maintaining its altitude at 100 meters
I agree that this would be a great feature.
Yesterday, 02:07 PM
Registered User
Quote:
Originally Posted by Sweetieinsf
I agree that this would be a great feature.
Likewise id like this please.


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Idea Vector Feature Request Rick01 Eagle Tree Systems 2 Oct 13, 2014 05:16 AM
Discussion Vector Feature Request Rick01 Eagle Tree Systems 0 Dec 06, 2013 12:04 PM