gif gif

The interesting corner

gif gif

DIY drone Pixhawk 4 Mini setup

Installing QGroundControl gave error:

/tmp/.mount_QGrounC2MWdm/QGroundControl: symbol lookup error: /tmp/.mount_QGrounC2MWdm/QGroundControl: 
undefined symbol: _ZNSt13runtime_errorC1ERKS_, version Qt_5
              
I installed this from here. This didnĀ“t work. I then tried to install v4.0.0 from the github and it worked.

firmware upgrade:

firmware upgrade

sensors overview:

sensors overview

Firmware upgrade met ardupilot en chibiOS (NuttX gaf geen available firmware):

ardupilot setup settings

Nadat ik dit had gedaan kreeg ik een error:

ardupilot setup error

Misschien is dit omdat er nog geen ESCs en motoren verbonden zijn?

Als ik opnieuw wil flashen zegt hij dat er 2 controllers verbonden zijn:

qgroundcontrol 2 pixhawks detected

Hierna geprobeerd met fmuv5:

ardupilot firmware met fmuv5

Dit gaf error "failed to upgrade IO firmware":

fmuv5 IO error

setup geprobeerd met PX4:

px4 firmware setup

Setup met PX4 gaat wel, sensor config gedaan en dat werkt:

px4 sensor config

Arm pixhawk without GPS or fly in Manual mode

PX4 disable radio check (fly without radio module) : set parameter COM_RC_IN_MODE to 1.

De drone heeft een Hexarotor x configuration. Hiervoor kan je in PX4 SYS_AUTOSTART = 6001 setten.

Basic sensor configuration werkt met PX4.

ESC parameters

Volgens de datasheet van de ESCs: 3.15V is de medium cutoff voltage voor de ESCs. Voor de 4S LiPo battery is dat dus 4*3.15V = 12.45V.

Voor de empty voltage moet de waarde boven de 3.15V zijn. 3.5V gekozen omdat dit hoger is dan de cutoff voltage van de ESCs en niet te laag zodat de batterij kapot gaat. Bij het setten van de Full voltage (4.05V) en de Empty voltage (3.5V), kreeg een error over missing parameters:

error battery missing parameters

Dit komt omdat PX4 nu gebruik maakt van BAT1_* parameters

Om dit op te lossen heb ik v4.2.4 van QGroundConntrol gedownload, maar dan kreeg ik dezelfde error als hierboven. Ik heb hier een issue van gemaakt. Uiteindelijk werkte v4.1.7 wel en die heeft wel de nieuwe parameters. Om de BAT1_V_DIV en BAT1_A_PER_V te setten moest ik ze eerst handmatig setten in de parameters, en daarna kon ik ze calculaten:

battery settings complete

Setting parameters on Windows

QGC op windows laptop geinstalleerd en PX4 v1.14 op pixhawk gezet. Hierbij kon ik wel de COM_RC_IN_MODE parameter setten:

COM_RC_IN_MODE parameter set

Ik moest de motor settings aanpassen:

motor settings

Voor de communicatie met XRCE-DDS heb ik de port hiervan en de MAV_0_CONFIG parameter aangepast:

motor settings
motor settings

De TeraRanger Tower Evo kan direct aan de pixhawk verbonden worden door deze video. De lidar heeft 12V voeding nodig.

Attitude estimation with quaternions

The position of an IMU is calculated with quaternions. Deze hebben een Real en 3 Imaginary parts. IMUs gebruiken verschillende frames of reference:

  • The Local-Level frame (ENU): hierbij wijst de z-as omhoog (aligned with gravity), de y-as naar het noorden en de x-as naar het oosten
  • The IMU body frame: Dit zijn de fysieke assen van de IMU
  • The vehicle frame: Hierbij wijst de y-as naar de voorkant van het voertuig, de z-as omhoog en de x-as naar rechts.

Ze hebben ook een inertial frame of reference die geen accelleratie heeft, maar alleen naar de draaiing kijkt.

Om hoeken zoals a graden te kunnen gebruiken bij het vliegen, moeten deze omgezet worden naar quaternions. Hier heeft MAVLink helper functions voor (source).

tait-bryan angles

tait-bryan angles

Zoals beschreven in de offboard docs (main) moeten eerst setpoint commands (ROS 2 OffboardControlMode) gestuurd worden met een snelheid hoger dan 2Hz voordat de offboard mode bereikt kan worden. Om de drone aan te sturen is de volgorde als volgt:

Gewenste positie: Ontvangen positie van API -> berekenen verschil met huidige positie beacons -> berekenen gewenste hoek -> drone naar punt sturen met attitude setpoints
Manual control: Ontvangen control van API -> berekenen gewenste hoek -> drone aansturen met attitude setpoints

Deze post geeft een Python algoritme voor het omzetten van yaw, pitch, roll naar quaternions.

NaN in C++: https://cplusplus.com/reference/cmath/nan-function/

Drone frames:
    FRD (body):
        X Forward
        Y Right
        Z Down
    NED (world):
        X North
        Y East
        Z Down

Messages:
    VehicleLocalPositionSetpoint: https://docs.px4.io/main/en/msg_docs/VehicleLocalPositionSetpoint.html
    TrajectorySetpoint: https://docs.px4.io/main/en/msg_docs/TrajectorySetpoint.html
        For velocity: velocity value needs to be different from NaN and position needs to be set to NaN
    VehicleThrustSetpoint: https://docs.px4.io/main/en/msg_docs/VehicleThrustSetpoint.html
    VehicleAttitudeSetpoint: https://github.com/PX4/PX4-Autopilot/blob/main/msg/VehicleAttitudeSetpoint.msg

Normalized thrust values means that it is mapped to a value between [-1,1], so -1 for 100% thrust down, 1 for 100% thrust up
    TODO test if value of 0 means hover or no thrust

dds topics:
https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/microdds_client/dds_topics.yaml
    hiervan kan ik /fmu/in/obstacle_distance gebruiken om de data van de lidar of sensoren door te sturen
    Hiervoor een ObstacleDistance message gebruiken:
        https://docs.px4.io/main/en/msg_docs/ObstacleDistance.html

planning aangepast naar week 12 (kalender 17), 13 (kalender 18) en 14 (kalender 19) voor
implementeren stabiel vliegen. De rest 2 weken opgeschoven en ML algoritme uit planning gehaald

TODO besturing:
    Heartbeat message is klaar
    testen VehicleAttitudeSetpoint of TrajectorySetpoint
    Als TrajectorySetpoint naar velocity kan is beter
        onderzoek doen naar wat deze waarden moeten zijn

    Voor VehicleAttitudeSetpoint onderzoek doen naar wat de waarden (q_d) moeten zijn

Positie:
    Positie vanaf beacons is in mm, positie voor PX4 is in meters, dus dit moet wel goed omgezet worden

Volgende week echt testen met beacons en proberen werkend te krijgen -> momenteel werkt uitlezen van 1 beacon maar niet tegeleijk
    Oplossing: 1 node voor beide beacons?
        publisht dan op drone/position/t0 en drone/position/t1 topics?

TODO ROS 2
    Node maken die data samenvoegt van objectdetectie en hoogtemeter
    testen als ik alles (lidar, multiflex, hoogtemeter) aansluit of het dan werkt -> parameters voor serial ports checken

mailtje sturen om te kijken of er iets 3D geprint kan worden -> vragen aan Gijs of hij het kan ontwerpen -> emailadres vragen

TODO verslag
    verslag updaten met vorderingen van deze week en onderzoek over setpoints en positie
    Als ik feedback heb van docent doorsturen naar begeleider

Bind USB device under a static name:
    https://unix.stackexchange.com/questions/66901/how-to-bind-usb-device-under-a-static-name
Terabee height meter and multiflex hebben dezelfde idVendor en idProduct. Misschien moet ik hier nog iets voor maken
                        

testing with simulation

Installed Ubuntu 20.04 VM through virtualbox, installed ROS 2 Foxy and cloned the git repo. Followed the ROS 2 user guide to setup the gazebo simulation:

PX4 simulation running on Ubuntu 20.04 VM PX4 simulation 1 running on Ubuntu 20.04 VM

However, the drone always wants to tip over. Not sure yet what the reason is.

TrajectorySetpoints

Sending trajectorysetpoints works. To make the drone fly up, the gravitational pull of the earth has to be accounted for. Also, to thrust up, a negative velocity must be given: #define D_SPEED(x) -x - 9.81.

How to control velocity for positio control in offboard mode?

Flying with GPS

HDOP en VDOP

vehicle local position:

timestamp: 1684240266019748
timestamp_sample: 1684240266018721
xy_valid: true
z_valid: true
v_xy_valid: true
v_z_valid: true
x: -32.12332534790039
y: 3.2880780696868896
z: 18.134044647216797
delta_xy:
- -68.334716796875
- -57.742286682128906
xy_reset_counter: 6
delta_z: -0.14385223388671875
z_reset_counter: 7
vx: 0.02078963629901409
vy: 0.047913286834955215
vz: -0.004041511099785566
z_deriv: 0.018253739923238754
delta_vxy:
- 0.07566811144351959
- 0.17246116697788239
vxy_reset_counter: 6
delta_vz: -0.3218432664871216
vz_reset_counter: 6
ax: 0.014298041351139545
ay: -0.005628574173897505
az: 0.007004101760685444
heading: -1.447838306427002
delta_heading: 0.1078571081161499
heading_reset_counter: 4
heading_good_for_control: false
xy_global: true
z_global: true
ref_timestamp: 1074334870
ref_lat: 51.4129736
ref_lon: 5.4514787
ref_alt: 38.57296371459961
dist_bottom: 0.10323143005371094
dist_bottom_valid: false
dist_bottom_sensor_bitfield: 0
eph: 0.7338472604751587
epv: 0.4494542181491852
evh: 0.2028583288192749
evv: 0.12513738870620728
dead_reckoning: false
vxy_max: .inf
vz_max: .inf
hagl_min: .inf
hagl_max: .inf

vehicle gps position:

timestamp: 1684240302333184
timestamp_sample: 1684235973959340
device_id: 11010053
lat: 514126538
lon: 54515989
alt: 33832
alt_ellipsoid: 80044
s_variance_m_s: 0.5610000491142273
c_variance_rad: 0.681372880935669
fix_type: 3
eph: 3.058000087738037
epv: 5.574000358581543
hdop: 0.8399999737739563
vdop: 1.2300000190734863
noise_per_ms: 99
automatic_gain_control: 1404
jamming_state: 0
jamming_indicator: 50
spoofing_state: 1
vel_m_s: 0.07600000500679016
vel_n_m_s: 0.07600000500679016
vel_e_m_s: 0.00800000037997961
vel_d_m_s: 0.021000001579523087
cog_rad: 1.883948802947998
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1684240302200214
satellites_used: 12
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

vehicle global position:

timestamp: 1684240711923419
timestamp_sample: 1684240711921533
lat: 51.41264334710265
lon: 5.451455579075605
alt: 32.834686279296875
alt_ellipsoid: 66.77375793457031
delta_alt: 13.289091110229492
lat_lon_reset_counter: 6
alt_reset_counter: 8
eph: 2.092191696166992
epv: 2.466698408126831
terrain_alt: .nan
terrain_alt_valid: false
dead_reckoning: false