image
Page 3 of 14 FirstFirst 1234513 ... LastLast
Results 21 to 30 of 134

Thread: A flaw in RTH...

  1. #21
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    Gothcya and good point. In my perfect storm situation I was at 'level flight' when this all happened. So the Gyro's just recalibrated with what it found at the time. Trust me I rather of had the plane dump itself close to base vs having it fly off like it did.

  2. #22
    GO HAWKS Hucker's Avatar
    Join Date
    Sep 2011
    Location
    Seattle, WA USA
    Posts
    3,046
    Quote Originally Posted by typicalaimster View Post
    I guess the question is would a capacitor give us enough surge protection when a jammed servo causes the power sag. Directly on the GPS I would say yes, but on the OSD/Flight controller itself I'd say it wouldn't. I do like the idea of not storing a new home location if the GPS is in motion.
    Not sure what AP you are using but the ones I know about have two inputs for power. Presumably you would have one connected to your main power source and the other a small backup battery (only powering the AP). A brownout is fully mitigated by using two Voltage inputs. This is a job for hardware not software.

    You are still left with your AP's watchdog resetting and recovering from that type of fault in which case you no longer need NVM or clocks since you can trust your data stored in ram on reboot (with appropriate CRC checks etc) and just use that data. Your GPS should still be on line so quick comparisons could be made with current/last position etc. I suspect that if the AP guys haven't planned for this condition it will be a bit painful to fix since you are almost certainly going to want to have different boot paths.

    Last year I designed a system that needed most of these features (not at all related to flying things) but the dual power source and multiple recovery paths coming out of reset using recovery data stored in RAM are easily in the realm of possibility.
    Last edited by Hucker; 9th January 2013 at 01:27 PM.

  3. #23
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    I agree that those servos should have been placed on the other rail and not on this rail. However humans are humans. The servos I was using did not draw power, under normal conditions, that placed me over the specificed rating of the voltage regulator. Sure redundent regulators and redundent batteries could have prevented the issue true. Had I placed this thing in Autonomous mode vs RTH mode the plane would have flown back to base after it had reacquired navigation. Sure we can build redundent hardware all day. If the software is not returning us to true home then what good is redundent hardware?

  4. #24
    GO HAWKS Hucker's Avatar
    Join Date
    Sep 2011
    Location
    Seattle, WA USA
    Posts
    3,046
    typicalaimster: we are in violent agreement and just disagree on the details. The idea that the AP should be smart enough to figure out that it is in the middle of a mission on reboot and 'do the right thing' is completely valid and should be well thought out. I'm just of the belief that the brownout failure mode should be mitigated in hardware not by tricky software recovery mechanisms that require more hardware (rtc/eeprom).

    The design of systems needing to 'do the right thing' with single point failures very hard design work. Most systems you get to say 'failed self test' and do nothing or just reboot. Total design time a few hours...I've been in meetings with a team of engineers arguing over hundreds failure mechanisms.

  5. #25
    Navigator
    Join Date
    May 2012
    Location
    San Diego, Ca
    Posts
    266
    Quote Originally Posted by Hucker View Post
    typicalaimster: we are in violent agreement and just disagree on the details.
    Indeed and sadly it's about perception. Text medium doesn't convey emotion. Seriousness is one of those emotions. SO I will yield to you Sir.
    Last edited by typicalaimster; 9th January 2013 at 02:00 PM.

  6. #26
    Navigator bankheadRC's Avatar
    Join Date
    Jan 2012
    Location
    Chi Town
    Posts
    25
    ? Are we talking a specific RTL or just any .
    I may be of topic ,but if you use a separate battery for osd / RTL would that help. I had tree batteries on my Skywalker , could have used 2 but wound with 3. One battery for motor power , one for servos and one for osd RTL . I changed later to a 2battery setup with a 10 amp bec for servos . 1 for motor with separate bec , 1for osd RTL so I didn't pull much amps from the battery that was giving power to the osd RTL .

  7. #27
    Instructor Pilot CaliDave's Avatar
    Join Date
    Feb 2011
    Location
    Northern California
    Posts
    2,799
    If I'm not mistaken, my ETOSD RTH will if turned on somewhat recently remember it's location and even pick up the sats locally that it had. For instance when I start the day I acquire sats, but when I change batteries the system fires up pretty quick, but it's true that it would think the new start point is home, and essentially loiter until the battery went out falling eventually to the ground.

    A hard GPS would be good if there was a failure, but how does it know when I take it home for the day that my garage isn't a fail spot and want to go back to the park?

    Additionally, while the RTH is important that suggests the plane is still in the air, and typically would have had to been not rolling over in the failure which I see as a big issue if there's a power loss or even brown out not supplying power to stabilize or provide thrust.

    I'm not as savvy on the techniques posted so far, but seem like good ideas, but how does gravity play into this, and changing locations so the system knows when you're starting fresh or coming from a fail?

    I would like the ability to have a hard location set into the system so if there was a failure it would simply come home, or loiter until the sats locked again and then come home, and then maybe through the menu you'd tell it a new location was setup and only operator initiated.

  8. #28
    Penguins Do Fly! paintz2007's Avatar
    Join Date
    Feb 2011
    Location
    Ohio
    Posts
    2,839
    Along for the ride, gonna check and see if i can turn off auto home on my ET osd tomorrow..

  9. #29
    Navigator
    Join Date
    Aug 2011
    Location
    Brazil
    Posts
    685
    Besides storing the HOME position in EEPROM, also store the flight status and IMU calibration parameters. An autopilot can probably fly reasonably well under some conditions using GPS+IMU only, but in higher winds are likely to fail or apply too much power to make the cruise ground speed. An airspeed sensor is needed to determine if the aircraft is in flight or not, which acquires data immediately after startup. Probably it requires a couple of control loop passes before the output data is consistent.

    When the flight status is "in-the-air" on CPU startup, then read HOME position from EEPROM and use IMU to level out flight pitch-wise until GPS comes back. GPS must have a backup capacitor, which reduces startup time to 1 second (so altitude control is not necessary within this assumed short time). If the flight status is not "in-the-air", wait for GPS to come online in 3D, then store HOME position and follow the launch procedure which eventually could set the status to "in-the-air". If the desired ground speed is not achieved, the launch procedure failed and throttle should be disengaged and disarmed.

    Another rule when in the general loop exists which checks on GPS positions only when valid 3D to determine if there's ground speed. If the ground speed and air speed is below some value for x GPS readings, assume the plane is no longer making way. It either has crashed or landed. Then change the flight status to "on-the-ground", update this in EEPROM and turn off throttle. If the power fails again on the ground, it won't engage throttle on the ground for a very short time.

    Ardupilot uses a "mux" chip, which switches the output between either the autopilot or the R/C RX through a specific channel on the tx, so if the RTH is totally hosed, there's a fighting chance that maybe power to the mux is still there. The complicating issue here is that most autopilots expect neutral pitch/roll values and mix the required outputs within the controller. This means that to have a fighting chance, you better be flying a tailed fixed wing instead of anything with elevons and you should ensure the control surfaces are trimmed out properly on the rods.

  10. #30
    I Like Waffles... SENTRY's Avatar
    Join Date
    Feb 2011
    Location
    Atlanta, GA
    Posts
    10,843
    Sheesh - thank God I don't use autopilots - you guys just gave me a headache. LOL
    "I Like Waffles" : FPVLab on Facebook and FPVLab on Twitter

Page 3 of 14 FirstFirst 1234513 ... 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
  •