[trust]

We're using a lot of Atom FCs and wonder if we can add GPS and minim OPOSD boards to the main & flex ports of the Atoms - not for flight control but only to get data relayed down through the OPOSD display, recorded on the ground.
The OPOSD are useful for getting battery status as well.
We also want to gather data on ground speed, climb rates, etc using the GPS as the reference.
We don't really need the magnetometer although it might be useful.
I gather the Atoms don't have the memory for full functions - but would any of this work?

[TheOtherCliff]

Atom is just a CC3D on a smaller board, so think of it as a CC3D.

Atom/CC3D does support Ublox (only) GPS and displays it on the OSD and relays the GPS coordinates back to the GCS.  These controllers do NOT do GPS flight modes.  They do not automatically configure the GPS, so you must do the GPS configuration yourself.  As I recall, these firmwares do not support modern mags.

If you really need to use DJI/Naza GPSs, and you build the CC3D firmware yourself, there is a reasonable chance that editing the CC3D build configuration to disable Ublox and enable DJI/Naza will work.  DJI/Naza don't need configuration, but they are a more expensive and a little less available (at least on eBay where I buy them).

The easiest way to configure the GPS is to use a Revo class FC with GPSSettings -> UbxAutoConfig set to AutobaudConfigureAndStore.  Make this setting in the Revo, power everything off, plug in the GPS, power Revo on with a flight battery (not just USB because that doesn't power the GPS).  You can watch the configuration process in GCS System page at DataObjects -> GPSPositionSensor -> AutoConfigStatus (and BaudRate and SensorType and Status).  It only takes a few seconds.  As I recall, this does enable an extra GPS message type that is not used on CC3D.

The other way to configure the GPS is to download and use the Ucenter program.
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/5669417/Configure+a+GPS+for+CC3D

After configuring the GPS, this page shows the CC3D setup.
https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/12812330/Setup+a+CC3D+for+GPS

Clarification: MinimOSD and also Micro MinimOSD are the hardware / boards.  MWOSD and MinOpOSD are firmwares that run on these boards.

It is recommended to NOT use MWOSD OSD firmware and FC settings.  There is not enough memory in CC3D for that anymore.  You should use MinOpOSD which uses native LibrePilot data and does not need the extra translation.  Here is a recent MinOpOSD thread that a developer very recently did.  Read it all and get the latest firmware since there was some testing happening.
https://forum.librepilot.org/index.php?topic=4938.0

[trust]

I have been using the latest OPOSD firmware you mentioned already - works fine now that we resolved the battery voltage issues (must set current sense parm to 0 when not used). So I gather that should work.
On the GPS - I mostly have the DJI/Naz GPS/mag combined units.
I thought the autoconfigure function was simply setting up the data rate to the GPS unit. Does it do more than that?
I do have some ublox GPS and Ucenter and have already configured them. I quit using them over the problem with the miniRevo onboard magnetometers and switched to the DJI/Naz versions, which seem a lot easier to use. I could try one of those.

[TheOtherCliff]

Sorry.  Of course that was you talking to @JDL.      I should check names better than I do. 

For Ublox GPS's, Revo class FCs can do combinations of:
- AutoBaud (different than just setting baud rate, detects baud rate of GPS and uses that to tell the GPS to temporarily use the requested baud rate, then switches to the new baud rate)
- Configure (temporarily tells GPS what kinds of GPS packets to constantly send out)
- Store (make the baud and config settings permanent in the GPS, not really needed since Revo configures at each power up, but for real paranoia, even on a Revo, if the GPS gets reset in flight the Revo won't configure it, so this will make sure that even works)
- Disable (after storing the GPS settings into the GPS, you don't really need to configure each time, so AutoBaudConfigureStoreAndDisable does it all, yes this is overkill and I wrote it )

For Revo class FC's the default is AutoBaudAndConfigure.  For CC3D the effective setting is Disabled where it just sets the FC baud rate and assumes the GPS will send what it supposed to at that baud rate.

DJI/Naza GPS's are hard coded to be effectively configured and stored, but use a different data language.
It would be an interesting experiment to see if changing the CC3D build configuration in:
flight/targets/boards/coptercontrol/firmware/inc/pios_config.h

from:

Code: [Select]

#define PIOS_INCLUDE_GPS_UBX_PARSER
/* #define PIOS_INCLUDE_GPS_DJI_PARSER */
to:

Code: [Select]

/* #define PIOS_INCLUDE_GPS_UBX_PARSER */
#define PIOS_INCLUDE_GPS_DJI_PARSER
would require anything more to get DJI GPS running on CC3D.

UPDATE 2021-01-03: It builds.  Set the baud rate to 115200.  It does display System -> GPSPositionSensor info but there is a memory size warning and GPS health doesn't know it is actually alive.  Headed to bed now.

UPDATE 2021-01-04: DJI GPS's runs at 115200 baud.  That is twice as fast as previous (Ublox) GPS's.  That means that the FC data buffers will fill up twice as fast.  That means that the GPS code needs to be called twice as often; every 2.7ms at the worst.  Round that down to 2ms.  In flight/modules/GPS/GPS.c
change this:

Code: [Select]

#define GPS_LOOP_DELAY_MS          6
to this:

Code: [Select]

#define GPS_LOOP_DELAY_MS          2
and change this:

Code: [Select]

    portTickType xDelay = 5 / portTICK_RATE_MS;
to this:

Code: [Select]

    portTickType xDelay = 2 / portTICK_RATE_MS;
This is actually an issue that affects Revo code too, although I have not seen any problems caused by it.    I need to create a Jira for this.

[trust]

I tried connecting my ublox GPS to the main port on an Atom FC and went in the hardware settings to change the port type to GPS - that I can do. But there is no change in the drop down list below that which allows you to set the GPS type - I can't change it.
I have the external power working,and I can see the GPS LED eventually starts blinking, indicating it has found satellites.
How do I set up the ports to see the GPS?

[TheOtherCliff]

There are several things to do and all must be done for it to work.  From memory...

Configuration - hardware page, do the obvious.    Set the port that you want, to GPS and set the GPS baud rate  (38K or 56k).  Press Save.

System Page - Settings - HwSettings - OptionalModules - GPS ... set to Enabled and use the red up arrow at top of screen to Save it.

Do all the Ucenter stuff in the wiki to tell the GPS what packets to send.  Set the GPS's baud rate to whatever the CC3D is set to.  ...or use a Revo class FC to set it up and store it in the GPS as per previous post.

Put a CC3D connector (JST-SH 1.0mm 4 pin) on the GPS.  You probably already have that done and tested.

[trust]

Success! Main issue after enabling GPS was baud rate - I assumed 57600 but after going through the ucenter set up again I noticed it was set to 9600.
Since no magnetometer the heading drifts around.
Some ground speed - even though not moving! But I noticed these all settle down after a while.
It would be nice to use the DJI/naz versions with the magnetometer too. Does it need a special build? If so could you make me one?
Thanks! This'll be a helpful addon to our existing aircraft. Then we can monitor speeds, climb rates, battery status. And keep the existing flight control settings without going to a different FC.

[TheOtherCliff]

With the aforementioned changes, DJI on CC3D builds and works but...

There is a memory size warning, so adding other stuff (like maybe OSD?), might make the memory size worse to the point of breaking if it's not already broken.  I haven't checked the scope to see how close the memory is.

Auxmag stuff is generally disabled in CC3D.  That would take even more memory.

GpsPositionSensor has a Heading which is the direction it is moving (not necessarily the direction it is pointed), so it is only valid when the vehicle is moving.  It is reasonably informative for fixed wing in light wind but obviously copters can fly backwards.  Fixed wing can fly backwards or sideways if there is enough wind.

Plugging my test DJI GPS into a Revo class FC seems to work a little better than in the CC3D.  Maybe the CC3D is dropping data?

I could build you a DJI CC3D as described above if you want to play with it and realize that I have not test flown it, etc.  I personally think that building the firmware is a small fun challenge and recommend it really to everyone. 

I will build it if you want.  No big deal, just a few minutes of time to do since I am already set up.  What versions?  Just 16.09?

Oh, and you would become the resident expert on what works and doesn't work with DJI GPS on CC3D. 

[trust]

I would actually like to try doing some builds of firmware. I tried accessing one of the github repositories and downloaded, but it seemed to be missing all the flight code. Where can I get 16.09 with everything?
I generally use Eclipse for cross compiling - don't know if that's necessary here. I haven't loaded it on this machine either.
  Do the "next" revs have any significant improvements in flight controls? It seems like it is more oriented towards other platforms, but maybe I'm missing the big picture.
  The DJI/naz units make the set up easier than the ublox plus they have the mag for absolute heading. Also in a nice sturdy package.
  Big picture for us is building more versions of our Hellaplanes with ability to hover in VR mode and perform waypoint missions. I'm still struggling with the mini-Revo FCs on an early version of the micro Hellaplane - it still won't stay in a hover in VR mode. I don't like the FCs due to the poor grounding - we need to hook up to servos and so have to do external grounding. The Atoms have heavy internal busses for the power and grounding so work more reliably - but obviously are limited in capabilities. The first gen micro is pretty beat up at this point so I've started building another 2nd gen micro which flies much better and is more solid than gen1, and plan to move all the flight electronics to it once finished.
 This isn't a commercial endeavor - we're just a couple guys trying to advance the state of the art in eVTOL with our own solutions, and having fun exploring and flying in the process.

[TheOtherCliff]

Where can I get 16.09 (source code) with everything?

When you do a "git clone" (on line) (see wiki) you get ALL versions of source code.  Then a "git checkout" (or or off line) gets the selected version from the .git directory into the source code root.

I generally use Eclipse for cross compiling - don't know if that's necessary here. I haven't loaded it on this machine either.

See wiki:  After the git clone, you do a "git help" to see what else is available.  It will have options to install compilers and libraries.  There are also some dependencies you will have to download and install, different for different OS's.  I use Linux.  You probably just use Windows.  After setup, you use command line "make whatever".  I personally just use a simple text editor and command line builds for firmware development.  Guys that do more GCS work will probably tell you something different.

Do the "next" revs have any significant improvements in flight controls? It seems like it is more oriented towards other platforms, but maybe I'm missing the big picture.

There is all kinds of stuff in next.  I forget.  New FC's.  New AttiEstAlgos.  Video stuff?  Fixed minor issues.  Bug fixes.
https://forum.librepilot.org/index.php?topic=4580.0
https://librepilot.atlassian.net/jira/software/c/projects/LP/issues/

The DJI/naz units make the set up easier than the ublox plus they have the mag for absolute heading. Also in a nice sturdy package.

You can get a uBlox with a mag, but it takes 2 ports (e.g. Main and Flexi).

I'm still struggling with the mini-Revo FCs on an early version of the micro Hellaplane - it still won't stay in a hover in VR mode.

You know my feelings on trying to get it working with FC in the fuselage with pivoting wing that has both ailerons and differential thrust.  I suspect that you could get a hovering pivot working perfectly if you don't try to get a compromise with forward flight pivot.  The thing is set up so that the FC knows e.g. that differential thrust controls roll, then suddenly it doesn't or the FC is set up to know that differential thrust controls yaw, then it doesn't.

[trust]

I got 3 long flight tests in with the Ublx GPS and the OPOSD setup on the Mini Hellaplane V2 and Atom FC. I was able to get a lot of useful data on airspeeds vs throttle, power needed for min power level flight, power for hover (2x level flight), and the pitch/bank indicator helps with FPV flying. One oddity - the climb rate indicator was always zero, although ground speed seems to display fine. I would think these would both be using the GPS data - or is it using the barometer for climb rate (none on Atom)?
  Have to fly 90 to wind to get best approx airspeed = groundspeed but still very useful. Also nice to now have the battery status indicator.
  I did loose GPS lock a few times - usually early in the flight - and I did take off a few times before it had fully stabilized GPS sats. But since the FC isnt relying on that for flight modes, didn't matter much.

[TheOtherCliff]

GPS vertical position is way less accurate than horizontal.  Revo EKF/INS13 fuses GPS vertical and baro in a way that basically uses GPS for initial altitude and from then on uses changes in baro.

I'm guessing that the features you mentioned use only PositionState and VelocityState (from EKF/INS13), and don't fall back to just GPS if PS and VS aren't available.

Groundspeed is available from GPS, but would have to be calculated from VelocityState.North and .East ... just guesses

[jdl]

I got 3 long flight tests in with the Ublx GPS and the OPOSD setup on the Mini Hellaplane V2 and Atom FC. I was able to get a lot of useful data on airspeeds vs throttle, power needed for min power level flight, power for hover (2x level flight), and the pitch/bank indicator helps with FPV flying. One oddity - the climb rate indicator was always zero, although ground speed seems to display fine. I would think these would both be using the GPS data - or is it using the barometer for climb rate (none on Atom)?
  Have to fly 90 to wind to get best approx airspeed = groundspeed but still very useful. Also nice to now have the battery status indicator.
  I did loose GPS lock a few times - usually early in the flight - and I did take off a few times before it had fully stabilized GPS sats. But since the FC isnt relying on that for flight modes, didn't matter much.

@trust: Do you refer to MinOpOSD JDL ? Which prebuilt firmware N# you had flashed to your MinimOSD? As Atom is CC3D in fact, you should use CC3D targeted OpOSD JDL firmware.

Please, confirm you are using CC3D targeted firmware build.

Otherwise, if it is Revo targeted, there won't be any climb rate data available.

No Airspeed sensor, and no Airspeed data, respectively, on CC3D!

[trust]

Yes, MinOPOSD JDL. I'm using the revo softreset code you recently uploaded.
Good point, I forget this is not the revo FC but the Atom or CC3D.
Which version should I use or can you make one with this configuration?
Not a big deal, I can compute the climb rate from the change in GPS altitude over time by reviewing the recording.
But I have to say it was very satisfying to finally have hard data on a lot of flight parameters for a change.
An airspeed sensor would be nice but I don't think I have any ports left to add one.

[jdl]

AFAIK no use of airspeed sensor possible with CC3D.

Here is a precompiled OSD .hex for CC3D Wing with LP16.09.

I've included (just for test purposes) a combination of (maybe useful) features that were never tested together as I don't have a plane/wing with CC3D FC with only battery sensor (without current sensor) connected to OSD.

Still, I hope they would be functional. If you find they work satisfactory with your setup, I'll include them in the list of prebuilt firmwares.

• UAVO definitions for LP16.09
• Wing
• CC3D FC
• Charset Uploader
• Batt Voltage sensor on OSD
• Battery Voltage to % Curve
• LiHV detection
• MAX7456 stalled state monitoring & soft-reset
• Safety Radius estimation based on Battery V%
• Efficieny Estimation / Glide Estimation

I'm sure that Efficiency Estimation won't work as it relies on data from current sensor and I guess your setup does not have one connected to OSD. However, when gliding with throttle off, it should display the estimated gliding distance.

Safety Radius estimation based on Battery V% - it might work... or not... I've added that code years ago but abandoned it after initial tests because it does not make much sense for park flier (my only quad with CC3D FC). Its idea is similar to Long-Term-Safety-Radius estimation, but uses changes in battery V% instead of the information from current sensor for actual energy used. Still, it might provide useful data when used on a wing with only battery voltage sensor connected to OSD...

If you'd like to test these Safety Radius / Glide Estimation features, don't forget to enable and (re)position them in the OSD Config tool.