Servers by jDrones

New OS free F4Light HAL

ardupilot

(night ghost) #41

I have never seen this board (nobody sends them for testing), so I can not be sure. But usually they are differs by minor changes, and should work. If that does not work, it’s easy to add support for a new board.


(chris rey) #42

Just ordered it one week ago for iNav purposes, https://www.hobbyrc.co.uk/airbot-omnibus-f4-v5-flight-controller but will give a try to confirm comptability as soon as I get it.


(chris rey) #43

hi, readme link is dead


(Andrea Belloni) #44

thanks
now the links are OK


(chris rey) #45

could you give your address to Airbot with a link to this topic? Sure they will send you a board mail@myairbot.com


(night ghost) #46

I asked him a year ago and received a refusal. I do not attack the rake twice.


(Henry Wurzburg) #47

I sure wish I could get some response on the issue of BAD AHRS on Omnibus F4 V2 when using EKF2/3. I have sent Tridge a note and posted on the Plane 3.8 forum. No responses yet…
This issue is preventing me from trying to test fly a plane with this board and HAL…

-I have recal’d ACCs many times
-Made sure the board is absolutely still during power up for gyro cal
-GPS has 15 sats and HDOP of 0.8 so 3d fix precision is not the issue.

Questions:

1.what is the impact of ignoring the warning and flying since everything on the ground seems 100% functional? or should we just disable EKF and fly ? At least DCM works well on Arduplane. Error seems to be horizontal position difference from GPS…usually ~10m.

  1. Is there a param(s) I can change to make it more tolerant? (If I change to EKF3 the gui warning goes away, but arming is still prevented with a “AHRS and GPS are different x meters” message…)

  2. Is there anything I can do to isolate the cause of the issue?

Maybe someone following this blog can answer the above questions…


(macfly1202) #48

@hurzburg : HI, I think I have the same issue as you about AHRS. I’m using Airbot v2 target (omnibus F4 pro v2) The only option I found for now was to desactivate Arming check to permit takeoff of my plane on the field. I suppose we must provide a little more info and console log to @night_ghost to see how this happen.


(Henry Wurzburg) #49

I think that it is dangerous to disable the pre-arm check…given that there are reports of fly-aways when falling back to DCM from EKF…I might try it disabling the EKF, keeping the pre-arm checks…I flew pre-EKF Arduplane for a long time, and it works well…


(night ghost) #50

this bug is fixed now


(macfly1202) #51

Thanks very much @Night-Ghost !


(chris rey) #52

Any chance on an Omnibus F4V3?


(night ghost) #53

Sure, use binaries for V2


(chris rey) #54

@night_ghost, I was able to flash f4light_AirbotV2.bin using the DFU util. Seems successful. But couldn’t find instructions for next step. I unplugged the board and replug it. The board led stays on green, and no usb connection detected. So I cannot set the parameters with MP. What am I dummy missing?


(night ghost) #55

Bootloader. First time you should to flash a binary containing bootloader - f4light_AirbotV2_bl.bin


(chris rey) #56

@night_ghost Thanks, I did this, now blue led is blinking, but when I connect to my PC I have a problem loading drivers:
3DR Virtual COM
serials USB (COM8)

do I have to install specific drivers? I had to install before Zadig for Betaflight…


(Andrea Belloni) #57

From what I know those drivers comes with Mission Planner.


(chris rey) #58

can connect all other controllers like Pixracer and Pixhawk to MP and QGC, with no problem. I also can connect my F4 omnibus boards to BetaFlight or iNav with no problem with the respective firmware, but after flashing following your instructions, the board is blinking blue, then I have a beep on my PC and I cannot select the USB port in MP.


(chris rey) #59

Ok, for me the solution was simply to remove and reinstall px4 drivers. https://www.rcgroups.com/forums/showthread.php?2784349-Ardupilot-on-OpenPilot-Revolution/page171#post39527687 And it works! I also tried to install with the iNav installer (hex file) and it works too, maybe simplier for dummies like me…


(Andrea Belloni) #60

I cannot build for f4light from ardupilot master commit 7718196 with make f4light in ArduCopter

andrea@galileo:~/src/ardupilot/ArduCopter$ make f4light 
Checking modules
echo "Generating MAVLink headers..."
Generating MAVLink headers...
#goto mavlink module directory and run the most recent generator script
echo "Generating C code using mavgen.py located at" /home/andrea/src/ardupilot/modules/mavlink/
Generating C code using mavgen.py located at /home/andrea/src/ardupilot/modules/mavlink/
PYTHONPATH=/home/andrea/src/ardupilot/modules/mavlink/ python /home/andrea/src/ardupilot/modules/mavlink//pymavlink/tools/mavgen.py --lang=C --wire-protocol=2.0 --output=/tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0 /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/ardupilotmega.xml; if [ $? -le 0 -o $? -gt 128 ]; then echo "mavgen: success"; exit 0; else echo "mavgen: failed"; exit 1; fi
Validating /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/ardupilotmega.xml
Parsing /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/ardupilotmega.xml
Note: message DATA64 is longer than 64 bytes long (74 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message DATA96 is longer than 64 bytes long (106 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message REMOTE_LOG_DATA_BLOCK is longer than 64 bytes long (214 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message DEVICE_OP_READ_REPLY is longer than 64 bytes long (143 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message DEVICE_OP_WRITE is longer than 64 bytes long (187 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Validating /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/common.xml
Parsing /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/common.xml
Note: message GPS_STATUS is longer than 64 bytes long (109 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message ATTITUDE_QUATERNION_COV is longer than 64 bytes long (80 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message GLOBAL_POSITION_INT_COV is longer than 64 bytes long (189 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message LOCAL_POSITION_NED_COV is longer than 64 bytes long (233 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message HIL_ACTUATOR_CONTROLS is longer than 64 bytes long (89 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message HIGHRES_IMU is longer than 64 bytes long (70 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message HIL_SENSOR is longer than 64 bytes long (72 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message SIM_STATE is longer than 64 bytes long (92 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message FILE_TRANSFER_PROTOCOL is longer than 64 bytes long (262 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message HIL_STATE_QUATERNION is longer than 64 bytes long (72 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message LOG_DATA is longer than 64 bytes long (105 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message GPS_INJECT_DATA is longer than 64 bytes long (121 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message SERIAL_CONTROL is longer than 64 bytes long (87 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message ENCAPSULATED_DATA is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message RESOURCE_REQUEST is longer than 64 bytes long (251 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message FOLLOW_TARGET is longer than 64 bytes long (101 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message CONTROL_SYSTEM_STATE is longer than 64 bytes long (108 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message AUTOPILOT_VERSION is longer than 64 bytes long (86 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message LANDING_TARGET is longer than 64 bytes long (68 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message GPS_INPUT is longer than 64 bytes long (71 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message GPS_RTCM_DATA is longer than 64 bytes long (190 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message HOME_POSITION is longer than 64 bytes long (68 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message SET_HOME_POSITION is longer than 64 bytes long (69 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message V2_EXTENSION is longer than 64 bytes long (262 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message CAMERA_INFORMATION is longer than 64 bytes long (94 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message CAMERA_IMAGE_CAPTURED is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message LOGGING_DATA is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message LOGGING_DATA_ACKED is longer than 64 bytes long (263 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message WIFI_CONFIG_AP is longer than 64 bytes long (104 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message UAVCAN_NODE_INFO is longer than 64 bytes long (124 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Note: message OBSTACLE_DISTANCE is longer than 64 bytes long (166 bytes), which can cause fragmentation since many radio modems use 64 bytes as maximum air transfer unit.
Validating /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/uAvionix.xml
Parsing /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/uAvionix.xml
Validating /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/icarous.xml
Parsing /home/andrea/src/ardupilot/modules/mavlink/message_definitions/v1.0/icarous.xml
Merged enum MAV_CMD
Found 215 MAVLink message types in 4 XML files
Generating C implementation in directory /tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0/ardupilotmega
Generating C implementation in directory /tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0/common
Generating C implementation in directory /tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0/uAvionix
Generating C implementation in directory /tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0/icarous
Copying fixed headers for protocol 2.0 to /tmp/ArduCopter.build/libraries/GCS_MAVLink/include/mavlink/v2.0
mavgen: success
Generating UAVCAN headers...
PYTHONPATH=/home/andrea/src/ardupilot/modules/uavcan/libuavcan/ python /home/andrea/src/ardupilot/modules/uavcan/libuavcan/dsdl_compiler/libuavcan_dsdlc "/home/andrea/src/ardupilot/modules/uavcan/dsdl/uavcan" -O"/home/andrea/src/ardupilot/modules/uavcan/libuavcan/include/dsdlc_generated/"
%% libraries/AP_Common/AP_Common.o
%% libraries/AP_Common/c++.o
%% libraries/AP_Common/Location.o
%% libraries/AP_Menu/AP_Menu.o
%% libraries/AP_AdvancedFailsafe/AP_AdvancedFailsafe.o
%% libraries/AP_Param/AP_Param.o
%% libraries/StorageManager/StorageManager.o
%% libraries/GCS_MAVLink/GCS_Signing.o
%% libraries/GCS_MAVLink/GCS_Param.o
%% libraries/GCS_MAVLink/GCS_serial_control.o
%% libraries/GCS_MAVLink/GCS_MAVLink.o
%% libraries/GCS_MAVLink/GCS_ServoRelay.o
%% libraries/GCS_MAVLink/MAVLink_routing.o
%% libraries/GCS_MAVLink/GCS_Common.o
%% libraries/GCS_MAVLink/GCS_DeviceOp.o
%% libraries/GCS_MAVLink/GCS_Rally.o
%% libraries/GCS_MAVLink/GCS.o
%% libraries/AP_SerialManager/AP_SerialManager.o
%% libraries/AP_GPS/AP_GPS_SBF.o
%% libraries/AP_GPS/AP_GPS_UBLOX.o
%% libraries/AP_GPS/AP_GPS_ERB.o
%% libraries/AP_GPS/AP_GPS_GSOF.o
%% libraries/AP_GPS/AP_GPS_NMEA.o
%% libraries/AP_GPS/AP_GPS_SIRF.o
%% libraries/AP_GPS/GPS_Backend.o
%% libraries/AP_GPS/AP_GPS_SBP.o
%% libraries/AP_GPS/AP_GPS.o
%% libraries/AP_GPS/AP_GPS_UAVCAN.o
%% libraries/AP_GPS/AP_GPS_NOVA.o
%% libraries/AP_GPS/AP_GPS_MTK19.o
%% libraries/AP_GPS/AP_GPS_MAV.o
%% libraries/AP_GPS/AP_GPS_QURT.o
%% libraries/AP_GPS/AP_GPS_MTK.o
%% libraries/AP_GPS/AP_GPS_SBP2.o
%% libraries/DataFlash/LogFile.o
%% libraries/DataFlash/DFMessageWriter.o
%% libraries/DataFlash/DataFlash_MAVLinkLogTransfer.o
%% libraries/DataFlash/DataFlash.o
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp: In member function 'void DataFlash_Class::Init(const LogStructure*, uint8_t)':
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:113:79: error: invalid new-expression of abstract class type 'DataFlash_Revo'
             backends[_next_backend] = new DataFlash_Revo(*this, message_writer); // restore dataflash logs
                                                                               ^
In file included from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:10:0:
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash_Revo.h:46:7: note:   because the following virtual functions are pure within 'DataFlash_Revo':
 class DataFlash_Revo : public DataFlash_Backend
       ^
In file included from /home/andrea/src/ardupilot/libraries/DataFlash/DFMessageWriter.h:3:0,
                 from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.h:33,
                 from /home/andrea/src/ardupilot/libraries/DataFlash/DataFlash.cpp:1:
/home/andrea/src/ardupilot/libraries/DataFlash/DataFlash_Backend.h:42:18: note: virtual void DataFlash_Backend::get_log_info(uint16_t, uint32_t&, uint32_t&)
     virtual void get_log_info(uint16_t log_num, uint32_t &size, uint32_t &time_utc) = 0;
                  ^
../mk/build_rules.mk:27: recipe for target '/tmp/ArduCopter.build/libraries/DataFlash/DataFlash.o' failed
make: *** [/tmp/ArduCopter.build/libraries/DataFlash/DataFlash.o] Error 1