ethz-asl / ethzasl_fw_px4 Goto Github PK

Describe the bug
While investigating for the cause of the crash in Davos, I am now able to reproduce a similar behavior where when a waypoint is far enough from the initial waypoint, the vehicle does not finish the loiter and starts deviating.

The vehicle is not able to recover from this and starts flying straight.

This behavior is only reproducible when using NPFG, but not sure if this is related to NPFG

@tstastny @nrjl @acfloria FYI

To Reproduce
Steps to reproduce the behavior: use branch: https://github.com/ethz-asl/ethzasl_fw_px4/tree/pr-develop-offboard-npfg

1. Simulate the believer vehicle (since it has NPFG enabled by default)

make px4_sitl gazebo_believer

2. Upload mission: https://drive.google.com/file/d/1Ds9zoFgfb41rhRgWzIkbDHAnd7BNePqL/view?usp=sharing
3. Start mission

Expected behavior
The vehicle follows the sequence of waypoints

Log Files and Screenshots
Flight Log: https://logs.px4.io/plot_app?log=b38bb0ad-52ea-448d-b18f-425c6e8b24c6

I am trying to set up the ETHZ terrain navigation project locally on Ubuntu 20.04 with ROS noetic. I faced the issue that the paths for some PX4 setup files and packages are different in the official docs compared to the ETHZ PX4.

The deviations from the official docs that I have had to do so far include:

1. Building PX4 without --no-sim-tools flag to get the gazebo targets

git clone https://github.com/ethz-asl/ethzasl_fw_px4.git --branch pr-hinwil-testing --recursive
cd ..
cd ethzasl_fw_px4
bash ./Tools/setup/ubuntu.sh

make px4_sitl gazebo

2. Paths for SITL gazebo setup.sh and the ROS package are different from the latest PX4.

px4_dir=~/ethzasl_fw_px4
source $px4_dir/Tools/simulation/gazebo/setup_gazebo.bash $px4_dir $px4_dir/build/px4_sitl_default
export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$px4_dir
export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:$px4_dir/Tools/simulation/gazebo/sitl_gazebo
export GAZEBO_PLUGIN_PATH=$GAZEBO_PLUGIN_PATH:/usr/lib/x86_64-linux-gnu/gazebo-11/plugins

Where should such documentation lie? My thought was that since we might eventually want to rebase ethzasl_fw_px4 to upstream, it might be safer in the terrain-navigation repo, or should it lie in ethzasl_fw_px4 itself?

I propose we maintain the working build instructions in either of these places as a pinned working instruction copy to make it immune to upstream changes in PX4 docs/paths etc for reproducibility.

I've seen a similar issue on the PX4 forums where somebody has struggled because of very similar reasons and similar outputs as my experience:
https://discuss.px4.io/t/mavros-posix-sitl-launch-is-neither-a-launch-file-in-package-px4-nor-is-px4-a-launch-file-name/30522

@Jaeyoung-Lim @Ryanf55

Describe the bug
A clear and concise description of the bug.

To Reproduce
Steps to reproduce the behavior:

1. Drone switched on '...'
2. Uploaded mission '....' (attach QGC mission file)
3. Took off '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Log Files and Screenshots

Drone (please complete the following information):

Additional context

Problem Description
When running #39 sometimes when executing path following, NPFG will sometimes deviate largely until it is pulled back to the path (not always)

Flight log: https://logs.px4.io/plot_app?log=af826970-0008-40b1-bb89-6fde91d25eb5

It seems to happen more offten after following long straight line segments, but not entirely sure

Describe the bug
The driver framework changed therefore the si720 driver no longer compiles with the latest PX4 upstream merge

To Reproduce
Steps to reproduce the behavior:

make px4_fmu-v5_default

Also it can be seen that CI fails since it is unable to compile si7210

Log Files and Screenshots

Additional context

• This was triggered by the upstream merge: #31 #33

Hello,

Does this modified firmware provide functionality to directly command motor rpm/pwm? I see that the mav_control_rw attitude controller publishes actuator commands. Is this implementable on real hardware?

Thanks.