I’m using the WASP 200 lidar, Pixhawk 4, and the latest arduplane firmware.
I’m getting the error message “Bad LiDAR Health” when RNGFND_LANDING = 1 which is what it’s supposed to be for autoland.
When RNGFND_LANDING is equal to 0 I don’t receive the error message but that means the lidar isn’t enabled for autoland anymore. Usually, the “Bad LiDAR Health” message happens when its set to 0.
In either case I’m getting accurate sonarrange data readings.
The distance ranges I’m measuring are within the max and min distance of the sensor.
Has anyone ever seen this before? Any help? Thanks
As one youtube commenter wrote: “Built entire plane from scratch, every technique and tune honed. Autopilot mission sorted and executed, and then documented “air-2-air” via well-honed FPV piloting skills. All by one man!”
Copter-4.0.0-rc3 has been released for beta testing! If you’d like to help us with beta testing please use the MP or QGC’s “Beta Firmwares” link to download this latest version which should appear in the next couple of hours. Alternatively the binary can be downloaded directly from firmware.ardupilot.org (in a couple of hours)
There are a large number of changes which are listed in the ReleaseNotes and also copied below:
Flight mode and control improvements:
a) Auto mode Takeoff getting stuck fixed (very rare)
b) AutoTune protection against ESC sync loss at beginning of a twitch
c) SystemID mode parameters hidden by default (set SID_AXIS to non-zero to see all)
d) Takeoff from slanted surfaces improved by reducing I-term build-up in attitude controllers
Lua Script related enhancements:
a) MAV FTP support to ease uploading and downloading Lua scripts
b) NeoPixel/WS2812 LED control from Lua scripts
c) Pre-arm check that Lua scripting feature has enough memory
TradHeli enhancements:
a) Autonomous autorotation (compile time option, not available in stable firmware)
b) CCW Direct Drive Fixed Pitch tail support (see H_TAIL_TYPE parameter)
c) Parameter description improvements
d) STAB_COL_1/2/3 param range changed to 0 to 100 (was 0 to 1000)
Lightware SF40c driver for latest sensors with “streaming” protocol
Board/Frame specfic fixes:
a) Hex CubeOrange IMU heater control gain tuning improvement
b) Holybro Durandal IMUs ordering fix so EKx_IMU_MASK bits are intuitive
c) Holybro Pixhawk4 B/E LED fix (was flickering)
d) MatekF765 PWM outputs 5 and 6 now functional
e) MatekF765, MatekF405 time wrap CRITICAL fix for vehicles flying more than 72min
f) MatekF765 LED fixes
g) mRobotics ControlZeroF7 I2C bus numbering fix
h) Solo default params updated for 4.0.0
i) Bootloaders for boards using STM32H7 CPUs
j) Bootloader protection against line noise that could cause the board to get stuck during bootup
k) LED timing fix for FMUv5 boards with LEDs on one of first four auxiliary PWM outputs
Minor Enhancements and Bug Fixes
a) I2C storm High level protection
b) Internal errors (like I2C storms) reported to GCS by setting Heartbeat status to Critical
c) Dataflash Logging CTUN.TAlt and SAlt scaling fixed
d) DO_DIGICAM_CONTROL messages are sent using Mavlink1/2 as specified by SERIALx_PROTOCOL
e) DO_SET_SPEED sanity check fixed to protect against negative speeds
f) FrSky telemetry scheduling improvement (fixes issue in which GPS data would not be sent)
g) GPS auto configuration fix for non-Ublox-F9 (F9 config was interfering with other Ublox GPSs)
h) Landing gear DEPLOY message fix (could be displayed multiple times or when gear not configured)
i) Pre-arm check of position estimate when arming in Loiter even if arming is “forced”
j) Pre-arm check that Terrain database has enough memory
k) RangeFinder parameter conversion fix (some parameters were not upgraded from 3.6.x to 4.0.0)
l) RangeFinder TYPE parameter descriptions clarified for LidarLite and Benewake Lidars
m) Serial parameters hidden if they do not exist on the particular board
n) UAVCAN GPS fix for GPSs that don’t provide “Aux” message (like the Here2)
o) NMEA Output bug fix (output was stopping after 90 seconds)
We are hoping to release 4.0.0 as the official version in as little as 1 week so we would greatly appreciate some rigorous testing to help us uncover any remaining issues. I plan to respond to as many posts as I possibly have time for over the next week.
If we do manage to get Copter-4.0.0 out next week (or soon after) this will have been a shorter beta period compared with previous major release (for Copter-3.6.0 we did 12 release candidates) but we plan to follow-up fairly soon after 4.0.0 goes out with a series of smaller point releases to address issues that turn up in newer features like BendyRuler.
Thanks again for helping us with beta testing this major release!
First time posting here after reading quite a bit of your posts here.
We’re a student team from Stockholm who are building a UAV controlled by the PixHawk 4 and have stumbled upon some problems with the different flight modes. Here’s what we’re working with.
Bicopter configuration with motor mounts capable of tilting in roughly ± 90 deg
Flight modes set to 1. Fly By Wire B, 2. QHover, 3. Manual
Start on ground in QHover, the tilt motors tilt upwards, away from the ground, and we throttle up. The plane gains altitude and behaves as a bicopter.
After the initial take off, we start to accelerate and switch the flight mode to Fly By Wire B where the plane transitions into horizontal flight. When this mode is selected the plane rotates its motors to a forward facing configuration after the correct airspeed and angle is achieved.
For landing the planes airspeed is lowered to where the angle of the wing body is high and it is flying close to stall speed. Here we switch back to QHover to land vertically.
Pretty basic! We’ve achieved this stable behavior before with exactly the same parameter as are currently on the Px4. But, before our first test flight of the take off procedure we simple couldn’t get it to behave as before. Instead we got this behavior:
The plane tilts it’s motors upwards when in QHover as before but now they move from +90 to -90 degrees extremely fast. They seem to react strongly to yaw input.
In both Fly By Wire B and Manual the motors tilt down towards the ground (-90 deg) and stay there no matter the orientation of the plane.
I just wonder if with just having a rangefinder facing down and setup the rngfnd_orient= 25, the drone will use this altitud for landing on RTL or any lading mode? Or may be i have to setup something else?
probably the battery rail came loose
The only strange thing was that during free fall the external LED was still green (seen on my recorded video), so I’m not sure. Maybe someone can take a look.
I’ve managed to get most everything setup based on the documentations and videos offered on a Align Trex 700e. There are some ambiguities such as getting a message after RC calibration stating throttle reversed in transmitter. I’ve tried the reverse channel 8 in the transmitter with no luck. I also tried reversing channel 8 in qgroundcontrol and still get the same message.
I am assuming that the RC calibration bars in the software should move right when given forward pitch but mine travels to the left, rest of the channels respond correctly. The helicopter’s swash responds correctly to my stick input and also the FC responds to helicopter movement by countering it. I’d appreciate it if someone can assist with getting past these 2 issues.
I read a ot of discussions about connecting the signal ground to a pixhawk or not. I want to ask the question in an other way …what if there is no signal ground on the Esc’s ?. I’m planning to use these …http://www.skystars-rc.com/Products/ESC/2019/1203/67.html …they dont have a signal ground ?!.
I am trying to find out if its possible to configure an aircraft to be a cross between a helicopter and plane. I would want to in essence mount a standard helicopter frame inside an airframe of a plane and use it to takeoff/land/hover, while still having a traditional forward thrust motor to use the aircraft like a plane for cruise. Is this currently possible? Thank you
I am a noob and I have just put together a quadcopter using Navio2 . When I armed the copter, initially all the motors were running but the copter wasnt flying! now I notice that one of the motors have lost power. But when I check individually the motors are working. Here’s the link to the logs. Can someone help me out please? Many thanks
If someone could look at my log I would appreciate it. This is a known stable aircraft with many flights. I removed a here link system and went back to conventional RC for some other testing. I had two full batteries of flight and one pitch and roll autotune on the airframe, I then replaced the battery and went out for a second AT. Part way through the pitch axis tune all motors stopped and luckily it was at low altitude and went flat down in the grass with no damage. I looked at the log and saw that power was uninterrupted but RCOUT cut off clean on all four channels. I looked for obvious wiring or connection issues and subsequently had two identical failures within the first couple minutes of flight. The attached log shows the event and i walked out to the vehicle and it remained lit so I re-armed and flew it back to the launch site. CubeOrange with Andy’s FFT master
(that combination has seen multiple good flights)
I am trying to connect a Gremsy Pixy U gimbal to a Cube via Telem2 using the following channels Pitch CH 10, Roll Ch 11, Yaw Ch12 with a Taranis X9D and X8R but I’m having no luck so far.
Could someone please help decoding some the below settings for me?
Is setting Type to ‘Storm32Mavlink’ correct when using Telem2?
Is selecting the ‘SERVOxx’ for Tilt, Roll, Pan correct or is this only when connecting the gimbal to the pins vs Telem2?
Does enabling ‘Stabilise xx’ mean the gimbal gyros signals will come from the Pixhawk instead of the gimbal?
I assume the ‘Input Ch’ selection sets the parameter MNT_RC_IN_xx?
After updating the requested rate for messages, it seems that in the SITL it periodically ramps up to the requested rate and then reverts to the original rate. For example if I change the attitude update rate to something like 10Hz it will periodically get up to 10Hz but then ramp back to 4Hz. I have tested this using both custom software and Mission Planner. Each behavior is the same per SITL, but works fine in the real world. Is this something I can change in a setting somewhere or overcome?
So I am going to attempt to build a quadcopter X8 drone. So, if you didn’t know, it has 8 motors, 4 facing up, and 4 facing down. I was wondering if it would be possible to use one set of 4 motors facing up, and a different set of motors facing down? In this case I would use a 40A 4-in-1 ESC for 4 3508 700kv motors facing up, and then 4 DYS 2836 1120kv motors facing down. The top motors would spin 1147 props and the bottom would spin 7030 props. Would this work?
good morning everyone, I would like to ask you a question about compass, and I have a pixhawk 2.4.8 fw 3.6.12 with two m8n gps and two compasses connected to the i2c splitter, and everything works properly, I tried to also insert the internal compass of the FC, but in the calibration phase I do not see it working while if I use the first external compass, and the second internal works well.
If, on the other hand, if the 1st external is used, the 2nd external and 3rd internal function only 1 and 2.
Is there the possibility of making all three work?
Thanks
