LibrePilot Forum
Development => Hardware => Topic started by: Anonator on October 02, 2017, 05:16:30 am
-
http://www.ebay.com.au/itm/Betaflight-OmniBus-F4-Pro-V2-Flight-Control-Built-in-OSD-BEC-For-FPV-Drone-Quad/322549210074?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D2%26asc%3D20140106155344%26meid%3D08bd3668f14f431ea0670c68342a3c6c%26pid%3D100005%26rk%3D1%26rkt%3D6%26mehot%3Dpp%26sd%3D262937521914&_trksid=p2047675.c100005.m1851
Can librepilot work on these F4? If not, what coding needed as they so cheap.
-
It isn't a simple task to add full support for a new FC and there is a concern that we need to redo that to make it better before adding a lot more FC's.
I see that this FC has an F4 but it doesn't say which one (could be researched) so it's not obvious how much memory or speed it has. FC dimensions are also not mentioned.
It appears that the baro has only has a +-1m resolution where the standard today is +-0.1m. +-1m is not very good for baro or GPS flight modes.
That means it is really just an F4 racer FC less suited for GPS/baro flight modes. It seems to me that F4 power is kind of wasted on racing where a lessor processor works well. It does seem to have a current sensor and OSD and it is cheap. I would try to use it with the firmware that already works on it.
It seems that @mr_w's F3 branch now supports this F4.
-
better link below - mpu6000, bmp280, stm32f405
http://www.hobbywow.com/en-betaflight-omnibus-f4-pro-v2-flight-control-built-in-osd-bec-for-fpv-racing-drone-quadcopter-p243981.htm
-
better link below - mpu6000, bmp280, stm32f405
http://www.hobbywow.com/en-betaflight-omnibus-f4-pro-v2-flight-control-built-in-osd-bec-for-fpv-racing-drone-quadcopter-p243981.htm
Omnibus F4 I am flying already. You can build mr_w/omnibus_f3_f4 branch from https://bitbucket.org/mindnever/librepilot.git.
I assume you know how to use git to add remote branch and switch to it.
Anyways, works just fine. Only thing is that you need to set UART1 from UavBrowser to S.bus, because there is no hardware page yet, but other things work fine.
This branch contains also other goodies, like fixed ASWA and ported super rate expo.
It flies really well, happens dev working on it is a racing guy :) Try it :)
P.S Here are my build from git instructions for this hardware https://forum.librepilot.org/index.php?topic=48.msg26090#msg26090
Under is the post from the dev who develops the branch and his video of FPV flying with it.
-
thx Mateusz, will order one for my fixed wing.
-
thx Mateusz, will order one for my fixed wing.
I guess you would be the first one to test it on fixed wing, but that's awesome, just what is needed.
I think the original Omnibus F4 is from Airbot.
But then there are a lot of derivatives Betaflight, HGLRC, FLIP, etc.... each flashable with Omnibus F4 firmware, as it is basically the same hardware.
As long as it says on hardware that it runs with Omnibus F4 firmware, then LP branch from mr_w will work.
-
My eBay version just came in today. I tested gyro, accel, baro on BF configurator. Tested OK. Note that I had to "sudo chmod a+rw /dev/ttyACM0" to give permission to chromium browser to access the board via USB. It looks like it doesn't see that I am a member of the dialout group.
This is the one I received. It is no longer the cheapest one. Cheapest is currently $14.28 shipped.
http://www.ebay.com/itm/Betaflight-OmniBus-RC-F4-V2-Flight-Control-Built-in-OSD-BEC-PARTS-For-FPV-Drone-/222665089731
I did
git clone https://bitbucket.org/mindnever/librepilot.git
git checkout omnibus_f3_f4
make -j4 gcs
make -j4 omnibusf4
make -j4 bl_omnibusf4_hex
After doing a git clone of the BF configurator, I did a "git checkout v3.1.1" in the BF configurator directory, then I ran chromium and used BF configurator to flash the LP bl_omnibusf4.hex that I built earlier. It worked fine.
I then did a simple LP manual rescue to flash the LP firmware that I built earlier. Make sure you then do an "Erase Settings" so that saving settings works correctly and consistently. Scopes say that gyros, accels, and baro are all working fine running LP firmware. I haven't tested the current sensor.
-
My eBay Omnibus F4 V2 (Pro) does not save settings. In the other thread, @mr_w said the SD card slot was not used for anything. Do I need an SD card or is my FC damaged or does the code not work with V2?
I don't see anything that looks like a memory/flash chip on this FC. F4 and MPU6000 on top side, OSD and switching power supply chip on bottom side. It looks like it would need to use F4 for this if possible and SD card if that is not possible.
My eBay Omnibus F4 V2 (Pro) (for pictures):
https://www.ebay.com/itm/Betaflight-OmniBus-RC-F4-V2-Flight-Control-Built-in-OSD-BEC-PARTS-For-FPV-Drone-/222665089731
link to statement "sd card not used"
https://forum.librepilot.org/index.php?topic=3868.msg26345#msg26345
Edit: It seems that it did save the change I made to HwOmnibusF4Settings, but it did not save changes to GPSSettings or AuxMagSettings even though I changed them at least 3 times each.
I did an Erase Settings and it seems to be working now. ::) ;)
-
Pulled out my OmnibusF4 equipped plane but cannot find firmware to update it. Using latest pull and compiling on linux. IIRC the GCS was updated to use it but no firmware is there. Please help.
-
If the flight/targets/boards/omnibusf4 directory is not there, then it hasn't been merged into your version.
I thought it would be merged in by now.
I've still got the old mr_w private build and it has that directory in it.
What does your flight/targets/boards directory look like? Might omnibusf4 have been renamed or merged in with something else?
-
No omnibusf4 dir in build. I have mr_w code as well but just moving it and adding target to makefile fails... Any hints?
-
Really strange...
[laurent@new-host LibrePilot]$ git checkout omnibus_f3_f4
Switched to branch 'omnibus_f3_f4'
Your branch is up-to-date with 'bitbucket_vladimir/omnibus_f3_f4'.
[laurent@new-host LibrePilot]$ git pull
Already up-to-date.
[laurent@new-host LibrePilot]$ make omnibusf4
- LibrePilot UAVObject Generator -
Done: processed 126 XML files and generated 126 objects with no ID collisions. Total size of the data fields is 5191 bytes.
generating flight code
CXX targets/boards/omnibusf4/firmware/main.cpp
CXX libraries/pid/pidcontroldown.cpp
[...]
PP pios/stm32f4xx/link_memory.lds
PP pios/stm32f4xx/link_sections.lds
LD ./build/firmware/fw_omnibusf4/fw_omnibusf4.elf
BIN/HEX ./build/firmware/fw_omnibusf4/fw_omnibusf4.bin
FWINFO ./build/firmware/fw_omnibusf4/fw_omnibusf4.bin.firmware_info.c
CC ./build/firmware/fw_omnibusf4/fw_omnibusf4.bin.firmware_info.c
BIN/HEX ./build/firmware/fw_omnibusf4/fw_omnibusf4.bin.firmware_info.bin
OPFW ./build/firmware/fw_omnibusf4/fw_omnibusf4.opfw
Please paste the output from the following commands :
git remote -v
git status
-
No omnibusf4 dir in build. I have mr_w code as well but just moving it and adding target to makefile fails... Any hints?
The problem is that it isn't that easy or it would already be in next. There are different ways of adding new FCs. The easy way is not as space efficient or as organized as it could be. I'm going to make a truly wild guess that the F3 code (ccf3d, nucleof303re, spracingf3, spracingf3evo) was done in the way that mr_w liked and he hasn't gotten around to refactoring the Omnibus code.
-
Thanks for responses :)
Got code compiled and all is working except the DJI GPS on com port 1. Telemetry works on either port 1 or 3 fine. Error - There is no GPS .... etc. Omnibus F4 Pro V2. GPS unit led has steady flash at about 1Hz. Got 57500 baud and DJI protocol in hardware tab. Has my GPS died or another possibility?
Cheers from Oz :)
-
GCS code may be incomplete. I recall @mr_w saying that you must use System->Settings page and set this or that Uart# in the HwOmnibusF4Settings. That is what I would try at least.
Are you sure you have it wired correctly? If power LED and other LED work, FC-TxD <-> GPS-RxD and FC-RxD <-> GPS-TxD.
-
Trying to checkout omnibus_f3_f4, but errors.
>MyLibrePilot/librepilot$ git fetch && git checkout omnibus_f3_f4
error: pathspec 'omnibus_f3_f4' did not match any file(s) known to git.
Please tell what silly mistake I have made...
-
I did
git clone https://bitbucket.org/mindnever/librepilot.git
(must do "cd librepilot" here)
git checkout omnibus_f3_f4
make -j4 gcs
make -j4 omnibusf4
make -j4 bl_omnibusf4_hex
Maybe you are looking in librepilot/librepilot.git instead of mindnever/librepilot.git (you must clone mindnever's private repo) or had not changed directories to the one which has ground and flight directories in it.
-
Thanks Cliff :) Cloned step missed lol.
Google Earth not working. Getting loads of errors as below...
Reply error: "Error transferring http://khms0.google.com/kh/v=810&hl=en-AU&x=964190&y=618805&z=20&s=Galileo - server replied: Not Found" QUrl("http://khms0.google.com/kh/v=810&hl=en-AU&x=964190&y=618805&z=20&s=Galileo")
Reply error: "Error transferring http://khms2.google.com/kh/v=810&hl=en-AU&x=964190&y=618804&z=20&s=Galile - server replied: Not Found" QUrl("http://khms2.google.com/kh/v=810&hl=en-AU&x=964190&y=618804&z=20&s=Galile")
QMutex: destroying locked mutex
QMutex: destroying locked mutex
-
Try 823 instead of the default of 810. In particular, set an environment variable called GCS_GOOGLE_SAT_VERSION to 823
In Linux, I can run the GCS from the source root directory with the command:
GCS_GOOGLE_SAT_VERSION=823 ./build/librepilot-gcs_release/bin/librepilot-gcs
-
Thanks again Cliff. GoogleEarth working. Is there a list of ENV variables with options?
-
$ find ground -type f -exec grep -Hi getenv \{\} \;
ground/gcs/src/libs/utils/synchronousprocess.cpp: const QByteArray path = qgetenv("PATH");
ground/gcs/src/libs/eigen/test/main.h: char *env_EIGEN_REPEAT = getenv("EIGEN_REPEAT");
ground/gcs/src/libs/eigen/test/main.h: char *env_EIGEN_SEED = getenv("EIGEN_SEED");
ground/gcs/src/libs/eigen/bench/spbench/spbenchsolver.cpp: if(getenv("EIGEN_MATRIXDIR") == NULL){
ground/gcs/src/libs/eigen/bench/spbench/spbenchsolver.cpp: matrix_dir = getenv("EIGEN_MATRIXDIR");
ground/gcs/src/libs/eigen/bench/btl/generic_bench/btl.hh: _config = getenv ("BTL_CONFIG");
ground/gcs/src/libs/opmapcontrol/src/core/providerstrings.cpp: QString envVersion = qgetenv("GCS_GOOGLE_SAT_VERSION").constData();
ground/gcs/src/libs/gstreamer/gst_util.cpp: qDebug() << "gstreamer - plugin system path:" << qgetenv("GST_PLUGIN_SYSTEM_PATH_1_0");
ground/gcs/src/libs/gstreamer/gst_util.cpp: qDebug() << "gstreamer - plugin path:" << qgetenv("GST_PLUGIN_PATH_1_0");
ground/gcs/src/libs/extensionsystem/pluginmanager.cpp: QByteArray ba = qgetenv("QTCREATOR_TEST_DIR");
Now as to what each one does, it would be best to examine the code or Google it, but you can certainly make educated guesses. There is little here that is useful to a typical user. The Eigen stuff looks like it is in test code. The only env var that I have heard tweaked is GCS_GOOGLE_SAT_VERSION
-
LOL I was just about to ask whether this controller works with LibrePilot.
Great to know! These ones are very cheap so a good way to start I think!
-
There is a private developer branch that has support for Omnibus F4. It is not part of 16.09 or even next yet.
-
https://www.readytoflyquads.com/flip32-f4
These are cheap, will they work with Omnibus version?
ps what will it take to integrate/merge the omnibus into main as Revo hard to get now and many ver Omnibus
-
Sorry. I missed this question and just noticed it.
That link seems to claim that this board is treated by RaceFlight as if it were an OpenPilot Revo. Of course it does not have an RFM22B telemetry module, baro, or mag, and it has some extra features not on a normal Revo.
The linked RTFQ ad says "The Revolution ... is a 6DOF with gyroscope/accelerometer only, no magnetometer and no pressure sensors and no radio link." Since each of those three things is obviously untrue for a real Revolution board, they must be talking about their board. I greatly suspect that their board would not work with LP Revo code and would fail because of the missing sensors. It may be fairly easy to change the LP code to skip the missing sensors, but then you would basically have an overgrown CC3D that can't do GPS flight modes but does support advanced features like RC receiver signal protocols, MavOSD, AutoTune, etc.
From the beginning of the ad; read it for a chuckle and what about those claims: :)
Tons of features in one board with a wounder full layout. Flip F4 ; Flip32 F4 With the low noise Gyro, optimal gyro placement recommended , and not an overly super inventive gyro that will require chasing down the PID tune
There is already a private dev fork that supports Omnibus F4 Pro (V?). The board version that has OSD, current sensor, baro, BEC, SDCard (unsupported?). At least that is the board that I have that it works with (it may support other boards too). This fork also supports some F3 CPU targets. This fork has not been merged back into the main code (next) because the simple way to do that adds more code in a direction that makes it difficult to add more boards. At least we (developers) should make some decisions and decide to spend some serious dev time (that we don't really have) on it. Doing it what might be a better way is a large effort and no one here is paid. :)
Next already supports some F3 boards.
-
Hi.
Any chances to see Omnibus support in near future?
-
next already has several F3 boards in it.
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 ccf3d
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 coptercontrol
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 discoveryf4bare
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 gpsplatinum
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 nucleof303re
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 oplinkmini
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 osd
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 pikoblx
drwxr-xr-x 4 cliff cliff 4096 Oct 16 2018 revolution
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 revonano
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 revoproto
drwxr-xr-x 3 cliff cliff 4096 Oct 24 2017 simposix
drwxr-xr-x 4 cliff cliff 4096 Oct 16 2018 sparky2
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 spracingf3
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 spracingf3evo
drwxr-xr-x 4 cliff cliff 4096 Dec 5 2017 tinyfish
and the aforementioned dev branch has Omnibus F4 in it.
That's all we currently have. I am not very up to date about what is being worked on. @F5soh might know more if he comes around and comments. :)
-
I know about SP3 support. It's main reason why I thinking to try LP.
However, before I could try it, I added some patches to the GCS, so that it worked as described in the wiki for firmware uploading. :)
And that worries me a little bit, because the project looks a little abandoned - the last commit was more than half year ago.