LibrePilot Forum
Users => Vehicles - MultiRotors => Topic started by: trust on May 17, 2019, 07:21:26 pm
-
I have a Revo mini and an OP GPS plugged into the main port, and the config in hardware set to use UBLK. The GPS is acquiring satelites - red LED is on blue LED blinks, but I get a red X over the GPS in status.
If I look on the status list the baud rate keeps changing and it indicates no gps. I assume its in autobaud trying to find a working data rate.
I tried U-center and I can see the NMEA codes coming out and satellites acquired.
But I can't change anything - I can't disable the child messages, and there is no UBLK items I can enable.
I'm thinking somehow this is a read-only GPS?
I tried selecting the NMEA option in Librepilot, and setting to the 9600 baud.
That doesn't seem to work either.
Thought maybe the RX pin not working in the GPS, but I tried it several times, no change.
-
Hi,
There is no need to use UCenter since the AutoBaudAndConfigure (https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12058679/GPS+setup#GPSsetup-ExtendedGPSoptions) option is selected and a GPS configured in Main or Flexiport with all defaults (UBX, 57600)
If you see NMEA messages with UCenter while UBX protocol is selected, the GPS is not configured automatically due to a wrong wiring or some hardware issue, look SystemHealth (https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669070/SystemHealth) for alarms.
Rx from GPS go to the Tx pin on Main/FlexiPort, Tx/Rx wires are crossed.
(https://forum.librepilot.org/index.php?action=dlattach;topic=4638.0;attach=8221)
-
The last version of the OP GPS has two usable ports on the GPS itself, they are labeled GPS only and GPS+MCU. GPS only can run at any baud rate, but GPS+MCU must run at 57600. If the GPS is configured to run at something other than 57600 then GPS+MCU will not work (see below).
You must have flight battery connected (via ESC or BEC) for the GPS to be powered. It seems you have that. GPS must be powered to change settings inside the GPS. :)
I suggest that you run default GPS settings (Ublox protocol, 57600 baud, etc.) and connect it to the GPS only port. See if it connects. If it does, change the UbxAutoConfig from AutoBaud to AutoBaudConfigureAndStore for 1 minute. (This will permanently configure the GPS to run at 57600 which is required on the GPS+MCU port.) Then set the UbxAutoConfig back to AutoBaud and leave it there. After this, you can connect it back to the GPS+MCU port and the GPS will run at the required 57600 baud.
-
The version I have, Cirocomm seems to only have one port, labeled with V G and T & R. On the off chance the lines were crossed I flipped them and tried that on Librepilot with the UBLK and 57600 setting and a reboot. No change. It seems to be hunting for the correct baud rate or its not getting the codes it wants, so keeps trying.
red led on and blue led blinking
-
Voltage, Ground, Transmit, Receive.
You got V and G correct since the LEDs light up. You also obviously have power (e.g. flight battery) applied. I assume that you get GPS power via the FC, and not some other power cable.
Does the GPS circuit board say OpenPilot on it? Are you even sure it is Ublox? I have several generations of OP GPS, and they all work with default settings as long as you have a working cable pugged in, have power (flight battery), and told the Hardware page which port you have it plugged in. The FC configured baud rate must be reasonable too. It doesn't matter what the GPS baud rate is, because it will be changed to whatever you have configured.
OP boards are configurable, some other non-OP Ublox boards are not configurable.
Do you have it plugged into the correct FC port (Flexiport vs. Mainport).
I would "Ohm it out" with power off and cables connected to make sure that GPS circuit board that connects to T pin connects to R on the FC circuit board. Sometimes a bent pin or other issue has the effect of a broken wire.
AutobaudAndConfigure (not just AutoBaud) really is magic and generally works to get any Ublox GPS (including OP) working as long as the cable is correct, there is power, and the baud rate is set to 57600. As I recall, it finds the current baud rate, changes it to 57600 (or whatever you have it configured to), configures the GPS to send the packets it needs to. In this mode, all changes are temporary.
-
The version I have, Cirocomm seems to only have one port, labeled with V G and T & R.
Cirocomm refers to the patch antenna brand, maybe you can post some PCB pictures or a link where you buy the GPS.
If you have access to it using UCenter, try disabling all NMEA messages and keep UBX messages On.
Even if the Ublox chip do not store settings permanently, the super capacitor will keep those settings for the test.
GPS only can run at any baud rate, but GPS+MCU must run at 57600. If the GPS is configured to run at something other than 57600 then GPS+MCU will not work (see below).
I suggest that you run default GPS settings (Ublox protocol, 57600 baud, etc.) and connect it to the GPS only port. See if it connects. If it does, change the UbxAutoConfig from AutoBaud to AutoBaudConfigureAndStore for 1 minute. (This will permanently configure the GPS to run at 57600 which is required on the GPS+MCU port.)
Talking about the GPS v9 from OP, changing the "GPS only" baudrate (Neo7 uart) has no effect on MCU<>GPS link since this link do not use serial/uart port.
-
Additional question: what GCS version do you use ? 16.09 or latest Next ?
-
Here's a link:
https://www.ebay.com/itm/OP-GPS-w-LED-for-Openpilot-CC3D-Revolution-EVO-Atom-Mini-CC3D/332166264277
I'm using rev 16.09
As for ohming it out, it's pretty clear it does transmit, as u-center shows the received data, and I did try swapping pins with no effect.
It does not seem to do anything with a received signal however. I can't change anything with u-center.
If I try to config and reset to defaults, nothing happens.
In the messages view, I can see items not greyed out under NMEA, but I can't disable any of these messages.
I also don't see any UBLK items.
-
As I recall, that kind does not save settings permanently. It doesn't actually work with OP/LP CC3D, but it still should work correctly with Revo set to AutobaudAndConfigure as it gets configured each time it is powered up (notice that the eBay item shows that a Revolution is connected). It does not have a mag/compass which is another things you usually need to fly GPS flight modes.
I suggested Ohming it out since you probably use a different cable / connector when connecting to UCenter. It would also be an equivalent test to configure your Revo as ComBridge so you would use the Revo instead of a USB to serial converter (FTDI), and thus you would use the same cables as during flight.
-
Can you try the following firmware with your GPS ?
Rescue > Load attached firmware > flash
Set speed to 57600 + UBX, GPS can be powered after you start the autoconfig.
Remember the UBXRate will be lowered if your use baudrate bellow 9600bauds.
-
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.
-
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.
-
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!
-
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.
VERY SCARY!
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?
-
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. :(
-
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.
-
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.