Hi, I am working on a rescue boat project. I am using pixhawk board with arduRover stack, To use skid-steer type, I have enabled “PILOT_STEER_TYPE = 1” and I am using Flysky Noblle NB4 transmitter with FGr4 V2 Receiver in which Ch1 is steering & Channel 2 is throttle so I have connected (IN1 of ppm encoder to CH2 of receiver & IN3 to CH1) when i press throttle Both the motors spin as usual but, when i simultaneously use steering only one motor spin & other stops, Rather than Both motors spin with difference in speed so that the vehicle can SKID-steer ?
How can I optimise the stabilization of my indoorloiter hover?
Is it possible to have an accurate stable hover (hanging still mid air)?
Video testflight:
Dataflash Log:
Project Link:
We did some testing with Pozyx. As it shows the drone doesn’t show the right altitude height from the barometer, which makes sense if you think about how the barometer works.
That brings us tot he real problem thats the minor drifts and corrections. The positioning on the maps looks sort of accurate with it’s actuall behaviour. The positioning is worrying me a bit, maybe its getting too many different BCN positioning reads, because I have made the update refresh rate from the tag & anchors pretty high. From testing it showed some faillures in the past with lower update refresh rates. This may be causing all the movements on the map, while in reality the drone is not moving all the time. Back when I tested only with the Pozyx and Arduino. The beaconing systems was giving a lot off different reads by an inaccuracy of plusminus -10 to 10 centimeters. The average is being calculated on 15 reads every second atm if I’m not mistaken.
The z-axis(vertical, height) measurements is not being used on the Pixhawk, because the z-axis measurements from the Pozyx is going negative during movement and needs quite some time to get an actual good/accurate read and even then it’s off with 20cm under or above the real height. As I contacted Pozyx about this, they admitted that the z-axis is not that accurate as the x-axis & y-axis and is using a different algorythm which is not finetuned yet.
Having a stable hover is necessary for my project and I try to find out if it’s even possible to have it hoovering completely stable in a Loiter/AltHold flightmode indoors? Did anyone already achieved this, if yes how? Did they use a Lidar/ OpticalFlow sensor or is this unneccesary to get a stable hoover? Which Parameters do I need to optimilase my current setup.
Drone setup:
PixHawk 2.4.8
Ublox M8N GPS Module (for external compass use)
I2C Split board
I2C USB module
Pozyx shield with Arduino
Anchor setup:
UWB settings/ update refresh rate: channel 2, bitrate 850 kbit/s and preamble length of 64
Apologies in advance for the slightly distracting movement of the Mission Planner in the video. I’m still learning the features of the OpenShot video editor.
Some notes about what’s going on in the video:
The vehicle is mostly in Auto running a simple back-and-forth mission between two waypoints following by a final RTL command.
The red circles are objects that are sensed by the 360 lidar and then stored in the 2D “object database”. Objects that are not seen for a few seconds disappear from the database and the map. During takeoff you’ll notice many circles appear this is just the lidar picking up the ground. To avoid these false objects affecting BendyRuler, I took off in Loiter and then waited a few seconds before switching to Auto. In the future I think we will need to change the database and BendyRuler to work in 3D.
BendyRuler does a reasonably good job of navigating around obstacles. It wanders a bit and sometimes avoids objects that aren’t really there (i.e. if the vehicle leans over too far and the lidar senses the ground) but mostly it does OK. I was especially happy with it’s performance around 5:19 when I purposely moved in front of the vehicle.
The vehicle’s altitude is a bit unstable. This is probably partially because of the wind blowing over the exposed flight controller and affecting the barometer but also the SF40C Lidar is really a bit too heavy for this quad.
I think the next two things we need to work on to improve BendyRuler are:
Enhance the object database and BendyRuler to work in 3D
pixhawk 1 is facing the problem of the BRD_TYP initializing problem while pixhwak 2 is not facing the same problem.
let me know if anyone is also facing the same problem
Hexacopter with pixhawk4 mini, arducopter 4.0. Frsky 2.4GHz link. I fly in auto mode. To have good view I was control model from window on second floor my house. When I seen that RSSI was low I change mode to RTL and when model was about 600m from home I go down to go ouside to land. During This time I loose RF signal. When I was outdoor I see that model fall down. On radio last message from telemetry was “Forcing safety off for watchdog”
There is to log:
First was cut just before crash and second during fall down.
Second log is long because pixhawk logs till I found it and switch off.
I wonder what was happens.
Now, I have never licensed anything from them, so I don’t have the faintest idea of their cost structure, BUT - maybe with the wide adoption of Ardupilot, they are open to give the community a break?
While the ins-and-outs are not detailed in the infos available, it might be worth to pursue by someone in the dev team that may have an inroad with NASA, so I at least wanted to put it forward.
Hello everyone, I have a question for the community.
I would like to load 2 or more missions on my plane, I explain:
I would like to load my mission, but in case of having to land early and without having to reload the mission by telemetry, to be able to switch through an RC channel to another saved mission that would only be landing; I would also like to have, for example, 2 or more landings saved to change them if the wind changes at the end of the mission. It would also serve to switch to a secondary mission in case of any inconvenience.
I think the main advantage would be the different landings saved with the convenience of switching through the stick on the transmitter. I would always be calmer to be able to change it that way, because I cannot always correctly load the mission with telemetry at first and, in the case of landing, it would be crucial to be able to change it in a second if the weather conditions change worse.
Our Client has recently won a large, classified defense project and is looking for skilled R&D Software Engineers who will be working with Px4 and Ardupilot.
Candidates need to have successful commit and accept experience - updating the code that is then submitted back to the community and accepted.
I used to read the page https://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html to connect my RPI to FMU end December 2019.
Now that I look at the page the content of the page has been updated and several critical information disapearded.
An example: From https://www.researchgate.net/publication/323683430_Communicating_with_Raspberry_Pi_via_MAVLink you can read “On newer versions of Raspberry Pi 3 the uart serial connection may be disable by default. In order to enable serial connection on the Raspberry Pi edit /boot/config.txt and set enable_uart=1. the build-in serial port is /dev/ttyS0. Once MAVProxy has started you should be able to type in the following command to display the ARMING_CHECK parameters value”.
This used to be visible on the web last month but not anymore
Hope someone can help me to retrieve the December 2019 content
Recently had a interesting event with a large X8 style copter that I would like some help with. During a test flight there was a sudden drastic departure of controlled flight that occurred once. The aircraft recovered and was landed safely, but determining the cause has been difficult.
The aircraft was in forward flight and reached a peak of around 6.5 m/s when the front right arm suddenly ascended. The copter pitched up to 32deg and rolled left to 45 deg (angle_max was set to 25deg). During the pitch/roll excursion the copter gained some altitude while CTUN.ThO dropped to 0.
Right now it is believed to be a mechanical or electrical fault. The first thought that occurred was that a motor or arm briefly failed in flight. However, the RCOU data does not show any of the expected peaks in output from trying to increase thrust on a dead motor/arm. Some of the outputs actually drop to idle during the event. None go above ~60%. Additionally, after a tear down and component testing we can not locate any potential cause.
If anyone has any time and can look at this log it would be greatly appreciated.
I am currently trying to learn how to set up custom log files within the Ardupilot code. I want to be able to manually record the flight sensor data, like the magnetometer orientations, accelerometers, gyroscopes, etc. I started off by building and running the AP_Logger_test.cpp example script on a Pixhawk1, but I got the following output:
Logger Log Test 1.0
TOGCS: Preparing log system
Failed to create log directory /APM/LOGS : ENOSPC
AP_Logger_File: buffer size=16384
TOGCS: Prepared log system
Unable to fetch Log File Size: ENOSPC
Log open fail for /APM/LOGS/00000001.BIN - ENOSPC
Log open fail for /APM/LOGS/00000001.BIN - ENOSPC
Using log number 0
Writing to flash… wait…
Successfully mounted SDCard (slowdown=0)
Average write time 0.1 usec/byte
Testing Write
Testing WriteCritical
Test complete.
No log file was generated, and it looks like the logger failed to open a log file on the sd card. I am not exactly sure what is wrong or how to fix it. I also tried it on a Pixhawk 4 with the same result Does anyone know how to get this code to work, or have any advice on how to record the sensor data in a log file? Thanks
So last night I saw a very cool quadplane. I have been looking on a regular basis because I am thinking I would like to build one. anyway I saw this cool one and then relized its using CW and CCW folding props and then I thought…where on earth did they did these up.
HERE+ V2 RTK Rover (External GPS) running 1.40 firmware - I am currently only using the rover module
mRo SiK Telemetry Radio V2 915Mhz
QGroundControl 3.5.5 as Ground Station
Problem:
I am trying to calibrate the sensors for an initial flight on a new drone I just built. When I complete the compass calibration, the new version of QGroundControl shows the quality of each compass’ calibration in a graphic. This graphic (see below) displays a low quality (red/yellow) calibration for the external compass and a high quality (green) calibration for the internal compasses. I have tried it several times with the same results. I do the calibration outside with the battery connected. The pixhawk is communicating to my laptop through telemetry. I’ve tried USB with the same results. The fact that the internal compasses have a high calibration makes me think that the environment and methods are acceptable. I don’t want the pixhawk to ignore the external compass in flight because it thinks the data is less accurate.
I have built drones in the past with similar setups. I would frequently get the error “PREFLIGHT FAIL: COMPASS SENSORS INCONSISTENT - CHECK CALIBRATION”. It would still let me fly, but it would throw that error when initializing. I was never able to figure out the problem, but I saw other people had similar issues. I suspect I am having the same issue now.
Questions:
Has anyone had this issue?
What does QGroundControl consider a “High Quality” calibration?
Why would the external compass have a significantly worse calibration than the internal compasses?
Does anyone have suggestions for how to get a high quality calibration on the external compass, specifically the HERE+ Rover?
I updated a Kakute F7 board to ArduCopter 4.0 using Mission Planner, and after that completed Mission Planner offered to update the bootloader, with a warning that this could take five minutes and might brick my board.
Is there more context on this somewhere? Like why I might need/want to update, or what’s the chance of bricking it?
I’m running a Matek F405 CTR in an F550 hex frame on the latest nightly (as of today) which has the BMP280 barometer. I have it sitting on my floor with no airflow in the room. For whatever reason the barometer is just constantly reporting readings that just keep going down into the floor…
Is there any way I can fix this or any settings that could be the issue? Could it be a defective barometer?
I am trying to simulate the GPS spoofing by sending the fake GPS data via the Mavlink message: GPS_INPUT. In the message, I include the information of latitude, longitude, velocity in north and east direction. All the information comes from the current state (i.e., vehicle.location.global_frame, vehicle.velocity in dronekit). When I try to run the simulation, at first, the drone flies with the given location as expected, then after a while, its heading changes dramatically, and velocity also experiences a huge increase. We do not know why this happens. Below is the log:
I am using mavproxy to connect to my mRo X2.1 flight controller on a HEXA X frame via a linux machine. From mavproxy, I ran “motortest 1 0 10 1” to see which motor it understands as “motor 1”. When I run this the motor labeled 4 in this diagram turns. Similarly, the following motors turn when I run the following commands:
So I tried setting the inverse in SERVOX_FUNCTION parameters without luck. Eventually i stumbled on the following settings which seem to work, but i have no idea why. The following settings seem to work in that running motortest x spins the motor labeled with that number in the diagram linked to above:
I have checked the wiring multiple times between my flight controller and my motors and they seem to be correct.
I would like to figure out why the above SERVOX_FUNCTION parameters work, but more importantly, Is the motortest experiment I ran the correct way to test this?
Copter-4.0.1-rc2 has been released for beta testing and should appear in the ground stations within the next couple of hours. The changes are in the ReleaseNotes and also copied below:
FrSky SPort Passthrough telemetry status text handling fix (Critical Fix)
Circle mode allows pilot control of radius and rotation speed
CAN servo feedback logged
Magnetic declination tables updated
Serial0 protocol forced to MAVLink (avoids accidental disabling of USB port)
Bug Fixes:
a) TradHeli RSC RC passthrough fixed
b) CubeOrange and Durandal I2C timing fixed (was running slow)
c) Compass calibration auto orientation skips “pitch 7” which could cause cal to fail
d) Durandal’s fourth I2C port fixed
e) Linux boards with CAN support fixed
f) Neopixel added to SERVOx_FUNCTION param description
g) NMEA Output fixed (was sending an extra CR)
h) Optflow messages sent even if EKF has no height estimate
i) SkyViper build fixed
j) Spektrum/DSM 22ms RC input fixed
k) “UC Node Down” message removed (was unnecessarily scary)
The first item is a critical fix meaning it resolves an issue that can cause vehicles with FrSky SPort Passthrough telemetry to crash. The issue was first reported this morning and we hope to release this as the official version within a few days. By the way, the independent CPU watchdog logging was critical in tracking down the issue because it logs some important state of the vehicle. This issue does not exist in Copter-3.6.x.
@Pedals2Paddles and I are very interested to hear feedback on the Circle mode changes (good or bad!).
Any other testing and feedback is also greatly appreciated!
Hi all, we are using an external parachute trigger because the pixhawk did not trigger our chute last time and it resulted in a very expensive crash.
We are using the SATS mini from Fruity Chutes but because this deployment hardware is independent of the PIX we need to shutdown the motors via an external signal from the SATS.
Is there a way I can get a pwm INPUT signal into the pix to do an emergency motor shutdown?
Can I use the AUX connections and change one from an output to input? Is there an easier way?
I recently took my copter for a flight. I was able to takeoff smoothly but it hovers to the right and backwards. It was hard to fly back the drone since I had to go all the way to the left to bring it stable. There is no PID control implemented and my trimming is set to default.
I have attached my bin file as well so that you guys can have a better understanding.
