Recent Posts

Pages: [1] 2 3 ... 10
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by TheOtherCliff on Today at 09:28:09 am »
As I recall, the way the 16.09 code is written, you need an FMS position for RTB.  The position is really for failsafe and failsafe can be set different ways.  One way is RTB.  You wouldn't want it to RTB if you were flying it from a boat.  Position Hold might be a better option.  As I recall, it won't arm if FC failsafe selects a switch position outside the range of the switch.  I personally think you should be able to tell it "to use the 4th position of a 3 position switch for FC failsafe (e.g. RTB)".  I made that code change on one of my aircraft but eventually removed the change since I have many aircraft but don't need RTB setup on many, and I should really put it everywhere or nowhere.

There is a work around for the average user to get e.g. a 4th position on a 3 position physical switch.  It requires that you use RC failsafe (the receiver continues to send pulses, but those pulses are set in the RC radio to be what you want for failsafe when you e.g. fly out of range) instead of FC failsafe (where the receiver stops sending pulses and the FC detects that, and uses it's own failsafe settings as set in the GCS).

Tell the GCS that you have a 4 position switch, then set your 3 position FMS to select the first 3 flight modes and set RC failsafe for the switch to be past this range and select the 4th FMS position.  Usually this can be done by starting with 4 positions in the GCS FMS setup and your switch channel putting out the full range of widths (e.g. 1000 to 2000 usec) during setup (or manually).  Set your RC failsafe to the 2000 usec position, then reduce the switch channel endpoint from 2000 to something like 1675.  The switch should then put out something like 1000, 1337, 1675 for the 3 positions, and 2000 when you switch the transmitter off.  Look on the Input page to make sure that each position is safely in it's desired range (not on the edge).  You can do some math and careful setting to get it right in the middle of each range, but it's not required.  Careful when testing by turning transmitter off because some transmitters require all switches to be switched a certain way and the throttle to be zero before they will turn on.  You would probably want to turn these safety features off.  It wouldn't be good to be required to start up at zero throttle, etc.

Switch the transmitter off or fly out of range and you get 4th position.

Be careful about flying RC over any USA national park and a lot of other parks too.  That includes a lot of forests and beaches.  USA national parks are rabidly "anti-drone" with a rule that bans it in all national parks.  I don't have personal experience with it, but I remember when they enacted the rule about 5 years ago.  (Personal opinion follows.)  They are going to have to do a 180 on that before I will consider helping national parks with anything to do with RC / drones (SAR, fire support, wildlife monitoring, drone knowledge, etc.) that I would gladly do for free otherwise; and my father was a USA NPS park historian.  I understand that it's not good to have a bunch of quad racers screaming around and running into people, but a middle ground could be reached.
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by trust on Today at 07:33:34 am »
I checked the pins on the main - none bent. Bad connection internally or dead io - hard to tell.

So I really don't need a separate RTB switch position? It will automatically do a RTB if I turn off the transmitter?
Is this a default mode?
I've never been a fan of having to do a unique arming sequence - but this is making me think twice about using it!
Thanks for all the help BTW. We've been using a bunch of Atom flight controllers in our experimental eVTOL planes and finally getting usable flight characteristics.

I lost a hang gliding friend recently - drowned. Rescue helicopters got to him too late. It's made me see the potential for our aircraft as potential rescue vehicles in an entirely new light. So I'm looking at what it takes to send destination coordinates - potential for automated response.
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by TheOtherCliff on Today at 07:00:34 am »
Set all your GPS settings to defaults, that includes using 57600 baud.  Use a magnifying glass to look inside your MainPort connector on the FC.  Do you see any tiny bent pins?

It sounds like talking to uCenter using your MainPort FC in ComBridge mode in place of USB to serial adapter would have failed too.

Always Armed should not be used except on an airplane after testing with prop off (cars and boats OK too, but be careful).  :(  "Motors Spin At Neutral Output" and "Always Stabilize When Armed" are other settings that should be studied, understood, and initially tested with props off.  :(

RTB is designed to come back to the take off location if you for instance run out of transmitter range, so it is designed to work with the transmitter "off".  As I recall, it won't let you arm in RTB mode, but you bypassed that by saying it is always armed.  :(
GCS General / Re: Settings not saved to CC3D Flight Controller
« Last post by TheOtherCliff on Today at 06:30:25 am »
Export just writes a computer file with the settings from the FC.

Import reads from a computer file and writes the flash memory.  Importantly, it does not erase the flash memory, mainly because the import file does not necessarily contain all settings.  This is like a computer re-writeable CD-RW disk.  The import file may just have for instance, just sensor calibrations, or PIDs.  I have several of these partial settings files.

Import assumes there are enough blank flash blocks to store all the settings.  I have never calculated exactly, but I believe that you can import several times before running out of blank flash blocks.  I have done this (imported several times without erasing settings) and not ran out of flash blocks.

It's recommended that you erase settings whenever it's easy for you, like when you are going to run the setup wizard, or if you are changing all the settings by importing them.  Note that even if the code did erase before import, that it would not help you here.  The problem seems to be that LP's EraseSettings does not work with some CC3D's in some cases; maybe with some recent clone CC3D's.  I can't say that I have ever heard of this problem on FC's other than CC3D.  Never for Revo, Nano, or Sparky2 as far as I know.
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by trust on Today at 06:11:00 am »
Ok. I was able to go through home location set, and calibration process successfully.

I set up a switch position for return to base.
But  a scary thing happened when I armed it. The motors started up!
I was holding it down in the center - but was trapped holding it! I couldn't reach the power plug!
After a while the motors died down somewhat, and with a somewhat herculean effort I lifted it with one hand and unplugged with the other.
I though that even always armed would not arm unless the transmitter was on.
Or is this so it can return to base if it looses signal?
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by trust on Today at 05:04:18 am »
Success! I decided to try plugging into the Flexi port instead of the main port. Set the baud rate to 9600.
The GPS is now GREEN!
And it is showing the correct gps coords in the system window!
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by trust on Today at 04:54:54 am »
Ok, I was able to rescue download the attached file and boot it.
No change. Same results. Status shows baud rate changing, but never settles to 9600 baud.
Vehicles - MultiRotors / Re: OP GPS can't change to UBLK
« Last post by trust on Today at 04:42:01 am »
Small progress. I actually got two of these GPS - one came with the Revo, another one I ordered separately. They look from the outside identical, but when I opened them up they have different markings and a different PCB.
My references here have all been to the second one with the Cicrocom marking.

I found the original one had oddly used a different color scheme for wiring - but the wires did seem to be connected to the right pins. When I hooked the correct pins to my FTDi adapter and ran U-center, this time I WAS able to disbalbe the NMEA messages, and enable the UBLK messages, and perform all the other items listed (although you tell me its not needed - config does this automatically?).
I could power it off and back on and the config seems to have been saved.

But when I hplug it into the flight controller and power everything up, it still seems to hunt for the baud rate and does not indicate the GPS exists.

How do I do the rescue load? Do I have to reset or halt the processor first? Rescue is greyed out.
GCS General / Re: Settings not saved to CC3D Flight Controller
« Last post by [email protected] on May 21, 2019, 11:30:35 pm »
Thank you for this quick response.
Unfortunately I was not able to get the CC3D connected to the Cleanflight or Betaflight Software.
It shows only "Unable to open port". So I can't launch the CLI to enter the flash_erase command.
In LibrePilot I still can't save the settings or finalize the Wizard with saving the Mixersettings at the end.

But I can successfully export and import the UAV Seetings (File > Export UAV Settings... and File > Import UAV Settings...).
What is the difference with this function?

Thank you.

kind regards Bernd
General Discussion / Re: Setting up for first flight.
« Last post by TheOtherCliff on May 21, 2019, 07:56:46 pm »
I recommend that you set transmitter trims back to the center (where you had them when you ran transmitter setup) (and leave them there) and adjust some settings until it shows level in GCS "Flight Data" to get it safer to fly before flying it.  You could adjust Attitude->Settings->RotateVirtual..., but if you get it level in INS13 (AttiEstAlgo) then it will fly off the other way in Basic.  :(

INS13 uses mag for compass heading AND FOR LEVELING.  Basic does not use the mag at all.  The problem is with the mag sensor alignment and world magnetic model causing INS13 to be a little out of level.  The following tells you how to adjust Attitude->Magnetometer->AuxMagOrientation so that your perfect Basic stays perfect because you adjust the mag orientation compensation angles to get INS13 hovering right.  First, in Basic AttiEstAlgo / Attitude flight mode, you get it to hover without drifting by adjusting RotateVirtual, then in INS13 AttiEstAlgo / Attitude flight mode you get it to hover without drift by adjusting AuxMagOrientation.  Be aware that Attitude->Magnetometer->MagUsage needs to be set to AuxOnly.
in the section titled "Fine Tuning Your Hover To Stop Drift (Not Required)"
Pages: [1] 2 3 ... 10