image
Page 1 of 14 12311 ... LastLast
Results 1 to 10 of 134

Thread: A flaw in RTH...

  1. #1
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266

    A flaw in RTH...

    I figured I'd start this discussion here instead of RCG since most of the experts in FPV have migrated over here. I'll preface this by saying the incident that I had is my fault involving a power module. This plane was set up for short range and was never supposed to leave a 3000' x 3000' box. My faults are my faults, so save the banter for another thread.. The purpose of this thread is to get folks thinking and discussing what RTH does and how we can improve that critical system we rely on when the shit hits the fan. We talk about policing ourselves and I'd like this to be a constructive thread. Not a bash fest!

    Background: I had a power sag while flying FPV that browned out my RC link, Flight Controller, OSD, and GPS. I know the flight systems started coming back up because the flight controller stabilized the plane. The RC Link did its thing by going into fail-safe which engages RTH.

    The flaw here is the fact that GPS needs time to acquire satellites before the flight controller can begin navigation. During power up the flight controller erased the 'home' location and waited until GPS lock has been acquired. At that point the place where the GPS lock has been acquired is considered the home location. In my case this satellite acquisition probably didn't happen until a good 45-60 second later. At which time the plane in question has already traveled 1.5-2km from base. GPS comes on line, and the Autopilot now circles above what it now thinks is home.

    Let's take out RC link and video link out of the discussion because they are moot. Let's focus solely on RTH and how we can prevent a runaway plane when GPS lock has gone astray for a moment but is reacquired later. There is a VERY good chance that the plane would have returned to base had I gone into autonomous mode as my fail safe. That being said, should programmers of controllers that bring us RTH allow us to hard program a RTH position vs assuming where the GPS locks is 'home'. Perhaps by flipping a few switches back and forth or something.

    I'll open the discussion to the group..
    Last edited by typicalaimster; 9th January 2013 at 01:33 AM. Reason: verbage

  2. #2
    GO HAWKS Hucker's Avatar
    Join Date
    Sep 2011
    Location
    Seattle, WA USA
    Posts
    3,046
    Wow, that is a good bug...I thought RTH systems had multiple power inputs to mitigate this faiiure mode.I know the RV5 has dual battery inputs. I suspect that rebooting an INS while it is moving around won't work too well.

  3. #3
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    Agreed and I don't think it's a bug that has really been thought of yet. We assume that we have good power going to everything. We also assume that we'll have GPS lock throughout the flight. In this case my flight controller had two sources of power going into it. One of those power supplies sagged and caused a reboot of the critical navigation systems. Yes GPS units with battery backups will reaquire faster. However how often do we change these batteries, and what is the MTTF for those batteries (and yes in some cases super capacitors). Plus cheaper GPS units may not have backup at all.
    Last edited by typicalaimster; 9th January 2013 at 01:57 AM.

  4. #4
    GO HAWKS Hucker's Avatar
    Join Date
    Sep 2011
    Location
    Seattle, WA USA
    Posts
    3,046
    Does your system really have a backup battery? Or do you have one for plane and one for video? Your description of a sag bringing down your system implies that you don't really have redundancy or failover.

    The way I would expect you to hook up a system like this would be to have your primary power source fed in to one Vin and a redundant backup battery into the second Vin. The OSD (RV5 and probably ruby) then would choose the highest voltage never letting your system loose power. This system a sag or failure of one power rail will not compromise the system and your AP/INS/GPS would just fly through it like nothing happened. As I mentioned above (and would love to hear from AP designers) I don't think hobby grade ap systems can reboot in flight and maintain a stable intertial lock.

  5. #5
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    Some GPS's have a backup power supply allowing them to do a 'warm' start vs a cold start. In my case the secondary battery like you describe would not have helped as one of my voltage regulators sagged. My flight controller will go into FBW mode until GPS navigation has been acquired and then will begin the navigation process. Tested this a few times on the bench by yanking the GPS while the unit was on.

    We can discuss power distribution and such but it doesn't solve the underlying problem.

    If a catastrophic event happens (Power, Software, Act of God) that both the GPS and flight controller is rebooted. Erasing our true 'home' position.. How do we prevent our true RTH location from being skewed?

    I do not doubt that this is happened before and people have chalked it up to pilot error that resulted in a fly away.
    Last edited by typicalaimster; 9th January 2013 at 03:07 AM.

  6. #6
    GO HAWKS Hucker's Avatar
    Join Date
    Sep 2011
    Location
    Seattle, WA USA
    Posts
    3,046
    You would need to store home in NVM and have a real time clock. If you are rebooted and are within a some configurable amount of time from the last NVM write then you could just load up the Home from NVM. As I've mentioned above your bigger problem is that your plane almost certainly is not flying straight and level so the AP won't know which way is up unless it was using IR sensors.

  7. #7
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    I hard set level in the software so I didn't have to 'level' my plane every bootup. Based on the sensor readings the system can correct itself and then maintain level flight.

  8. #8
    Navigator cardboard_boks's Avatar
    Join Date
    Nov 2011
    Location
    Wellington NZ
    Posts
    891
    I wrote my own RTH code and thought through this very question. It uses a 328p for all the ppm reading and navigation stuff then hands off the servo movments to a multiwii board configured for fixed wing.
    Although not implemented yet my solution to the data loss issue is to write the home location to the eeprom, then every X minutes write the current time to the eeprom as well (although the above mention to use a real time clock seems like a far better solution). Whenever the system is power cycled it will compare the time from the GPS to that of the stored in the eeprom, if the difference is less then a handful of minutes the controller will then use the stored home location as the "real" home and go there. If the time difference is greater then it will amuse that you are powering it up for a new flight and will create a new home location.

    The other option is to have a manual set home position button that writes the home location to the eeprom and until that button is manually pressed again the plane will always return to that spot.

    The other feature that has been brought to my attention is the lack of a "smart" RTH. Currently all RTH units come straight home without regard to terrain or anything in their way, likewise if you are mountain climbing and RTH kicks in but tries descending to the RTH altitude you may end up a case of controlled flight into terrain. The plan is for a RTH that would backtrack its way home. So every 30s the flight controller would log location and altitude, if RTH is enabled it would then fly to the waypoint that is both closest to its self and the one that is the shortest distance from home. In theory this would cause the aircraft to backtrack home taking the shortest route that is known as safe (it knows it is safe is it flew there early in the flight. There are details such as if you were ground skimming you'd want the RTH altitude the logged altitude + 100f and if you wanted to avoid data loss in a brown out then the data should be written to some non volatile memory.
    Last edited by cardboard_boks; 9th January 2013 at 05:41 AM.

  9. #9
    Engineer for Jesus Christ IBCrazy's Avatar
    Join Date
    Mar 2011
    Location
    Amherst, VA
    Posts
    7,352
    Quote Originally Posted by typicalaimster View Post
    Some GPS's have a backup power supply allowing them to do a 'warm' start vs a cold start. In my case the secondary battery like you describe would not have helped as one of my voltage regulators sagged. My flight controller will go into FBW mode until GPS navigation has been acquired and then will begin the navigation process. Tested this a few times on the bench by yanking the GPS while the unit was on.

    We can discuss power distribution and such but it doesn't solve the underlying problem.

    If a catastrophic event happens (Power, Software, Act of God) that both the GPS and flight controller is rebooted. Erasing our true 'home' position.. How do we prevent our true RTH location from being skewed?

    I do not doubt that this is happened before and people have chalked it up to pilot error that resulted in a fly away.
    ^This. If you have a brown out and RTH engages, you are hosed unless your control system comes back online fast enough to give you control back.

    There are a few good solutions:
    1. Memory back up capacitor in the OSD. These are cheap and are designed to hold memory. Many GPS also have a back up capacitor to get online fast so no need to install one on the GPS too.
    2. Time delay on RTH engagement. This gives your system time to recover before RTH kicks in. If RTH engages, your airplane usually has a lot of time before the ground comes up and meets it.
    3. Failsafe to loiter mode. This keeps the airplane in place rather than tryign to fly it somewhere.

    I like option #3, but that's just me.

    -Alex
    If it is broken, fix it. if it isn't broken, I'll soon fix that.

    videoaerialsystems.com - Performance video piloting

  10. #10
    Im lost
    Join Date
    Apr 2011
    Location
    Rio Brasil
    Posts
    2,891
    very interesting. there is a simple fix to this:

    program the AP to save the HOME position in the EEPROM
    when everything comes back, the home position is read and everything is fine.
    the pilot would have to set home everytime though... because it would be stored until he changes it. ... or program your home at all times... if you have a failure, just drive home to find your plane. lol.
    seeing the world through a security camera

Page 1 of 14 12311 ... LastLast

Similar Threads

  1. Fast shipping from RMRC, just one minor flaw
    By Wearyman in forum ReadyMadeRC
    Replies: 12
    Last Post: 15th October 2013, 06:52 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •