@amitmanish wrote:
Hello everyone,
I am working on a big project of mine of making a heavy drone probably around 100kg. The doubt i have is that if pixhawk will be able to fly at this extreme conditions or i will have to add external sensors.thanks
Posts: 1
Participants: 1
@otk1fd wrote:
Hello.
I am trying to connect LIDAR-Lite v3 to Pixhawk by PWM for Alt_Hold and FlowHold flight mode.
But It dows not work well.I setted Pixhawk as below.
- ArduPilot Copter 3.6.3, Quad X
- I setted parameters according to wiki guide.
- I wired Pixhawk and LIDAR according to wiki guide.
- LIDAR is not died. I checked with two LIDAR-Lite v3 but behavior is same.
- I made a cable for PWM connection.
- Connector cable is conducting very well.
- I setted parameters SERVO5_FUNCTION and SERVO6_FUNCTION to Motor5 and Motor6 for my purpose.
- 5V BEC is connected to servo rail (AUX1).
Mission Planner shows sonarrange = 0.
dronekit-python Vehicle.rangefinder return None.Do you have some idea to improve this problem?
Posts: 1
Participants: 1
@Naterater wrote:
Is there any information about the timestamp feature that is supposedly available with the Here2? We’re looking for precise photo timestamps with good GPS locations.
Posts: 1
Participants: 1
@franky464 wrote:
I’ve experienced few times that my copter in Mode Auto, when it started to gain altitude it seems it could not stop climbing.
Switched to RTL the copter immediately react, changes its intierary back to launch but still climbing instead of descending.
A couple of time my copter climbed over 100 meters in both Auto/RTL modes switching to Loiter immediatlely reacted to command.
What is strange is that this did not happened all the time any other flight encountered no problems at all with perfect altitude control in AUTO & RLT.
On this picture when i launched Auto the copter was more or lesse to its targeted altitude 100 (1000 on the graph as its rescaled for lisibility) we can see that the copter as reach more than 100 meter above the requested altitude.RTL did not change the comportment loiter did immediatly.
-No radio problem as the Ardupilot reacted to the commandes immediatley.
-No problem with GPS / Baro as the values are consistant in the log.
=After further investigation i found, well not the cause but at least i could recreate the phenomenom.
In fact it appears that in the fisrt minute the copter has pain to stabilise its altitude (with the GPS), well i take off on Loiter, then the Throttle to middle the copter is climbing, when i low the Throttle down the copter drops, pushing up again it climbs, again, afer 5 or 6 cycles like this well the altitude finally gets stabilised.
If i dont do this it will climb and climb, looks like it need to reach 1mn of stabilisation first to control properly its altitude after this the mission is really accurate (i made few jumps) it goes perfectly on the same path (even altitude).
On the photo attached (2018-12-24-17-42) you can see the 1st minute of flight where the baro altitude seems not consistant with the GPS one it trends to match then is ok.
My understanding is that it takes nearly one minute to have the GPS altitude consistant to the baro’s until this the NKF can use the altitude stabilisation, I mean until it only stabalize is that correct ?
Posts: 1
Participants: 1
@josheeg wrote:
I used ctrl + Middle Mouse Button to pull up the menu of xterm and stop the screen scroll to debug the differences of Rascal running in JSBSim vs another JSBSim aircraft Boeing314 has more lines of code and I don’t see the error with what I can see. It allows me to uncheck scroll on tty output. Then I used KDiff3 to look for the differences after copy paste them to a txt editor.
Why wont Boeing314 takeoff?
mode auto
arm throttle
Posts: 1
Participants: 1
@josheeg wrote:
The copter does not move on the map?
I have gotten the Rascal to take off but no other planes in jsbsim or aeromatic++
When I fallowed these instructions some things seemed to update. But the copter does not move on the map?
Posts: 1
Participants: 1
@AndrejSl wrote:
Hello, i just noticed that only the RSSI_TYPE parameter is found in mission planner when searching parameters.
I am using ArduCopter V3.6.3 (tried with ChibiOS and without) and MissionPlanner 1.3.62.
The board is Pixhawk 2.
Posts: 2
Participants: 1
@ArduNoob wrote:
I would like to view Voltage/Current readings after flight via the KMZ file in google earth. Right now all that’s obtanable is the flight path in google earth. Is there a way of showing alternative flight data? Many thanks
Posts: 1
Participants: 1
@DrPop wrote:
After reading about the benefits of ChibiOS, I flashed my daughter’s quad with a (then working) Radiolink Mini-PIX flight controller to the latest ChibiOS based Arducopter 3.6.3 firmware through the regular Mission Planner. (Previous to this I had only used the Radiolink branded Mission Planner.) After reading several threads on various forums, I realize this flight controller is not a “true” Pixhawk, but does seem to work most of the time, and it always worked well on the old Radiolink branded firmware.
It goes through the whole wizard fine in the regular version of Mission Planner with the new firmware, and everything seems to be OK except the quad won’t arm anymore. This is the error we’re getting now:
No IO Thread Heartbeat ()
PreArm: Logging failed
Frame: QUAD
mini-pix 00280026 3436510A 35393336
ChibiOS: ff603d11
ArduCopter V3.6.3 (63eb66fe)It seems to be a logging problem - either it’s trying to put a log file somewhere that doesn’t exist or something like that. This flight controller has no SD card that I know of, though it may have a small flash area for storing a log? Does anyone know some steps I can try to fix this logging error to get it to arm again?
I also tried reverting it back to the old Radiolink branded firmware through their own mission planner version, but it looks like that won’t work now that we’ve gone from the Nuttx OS to ChibiOS.
Thank you for any help!
Posts: 1
Participants: 1
@rmackay9 wrote:
After about a week of beta testing, Copter-3.6.4 has been released as the official default firmware for multicopters and helicopters and should appear in the ground stations within the next hour or two. The changes are in the ReleaseNotes and also copied below:
- Bug fixes and minor enhancements
a) Detect and clear stuck I2C bus when using ChibiOS. May help some Radiolink TS100 GPS/compass module users
b) Pixhawk4 fix for battery monitor voltage scaling
c) TradHeli Dual (aka Chinook) fix for scaling of second swashplate movement
d) Omnibus F7 IMU orientation fix
e) Gimbal fix to avoid extreme movement if pilot’s transmitter is off at startup
f) Follow mode fix to obey FOLL_SYSID parameter (controls which vehicle to follow)- Cheerson CX-OF optical flow sensor support (wiki)
We still have some known issues that we are working through including the persistent “Bad Logging” message that some users are seeing.
Thanks as always to our beta testers for helping us test it!
Posts: 2
Participants: 1
@arshiyathukral wrote:
I am trying to control/set speed of my dc brushed motor using cytron dual channel motor driver in manual and auto mode. But no matter which parameter i change, speed never drops to zero when i bring my left stick down or max when i bring it up. When armed it starts with random speed. And when i bring the stick down to trim it slows down a bit and speed up a bit when brought to both the extremes in manual mode.
Also, in auto mode after arming motors they start running at random speed. I have tried changing cruise throttle and cruise speed but nothing changes the speed. Please help.
Posts: 1
Participants: 1
@gsot wrote:
I am new to PX4 and Y6 drones.
I have been unable to successfully take off.
I have been thru the calibration process many times.
My first impression is that the drone is too heavy, however the ecalc specs that I used to select components states that I should be ok.The rig I have built includes:
Y6 Frame
PX4 Controller
XRotor 40A ESC (BLHeli_32) - configured in PX4 to use regular PWM not oneshot.
Gartt ML5008 330KV Motors
15Inch Props Pitch 5.5Attached is a link to the logs of an attempts to take-off and plus the ecalc specs.
https://1drv.ms/f/s!Ao1uvOAo0KZBqAbeYKykEHEzCbpg
Any help much appreciated. I have been having issues with this for 3 months so far.
Posts: 1
Participants: 1
@Chad_Frazer wrote:
range for this parameter is 1-10, can anyone confirm if the units are meters, cm, feet or AU’s?
Posts: 2
Participants: 2
@Alexander_Perez wrote:
I just installed the arduplane firmware as instructed on the ardupilot website (http://ardupilot.org/plane/docs/common-omnibusf4pro.html) using the F4 Omnibus Pro board. To ensure continuity, I’m using the same exact board. Installation was done using BetaFlight and had no issues. In mission planner (and also checked in qGroundControl) all works correctly except the roll (in the glidescope HUD) is mirrored. If I bank the board to the left, the HUD shows it as banking to the right. However, pitch and yaw all work fine. In an effort to check and make sure the board was not the issue, I installed the regular BetaFlight firmware and checked the acelerometer in Beflight. All worked flawlessly without a hitch. Therefore, my suspicion is either the latest firmware (also tried the release from December 1 2018) or perhaps some hidden setting in the general parameters. Can someone please assist? Thank you in advance.
Posts: 2
Participants: 2
@Awilonk wrote:
Hi there:
I found it useful adding a pause landing function while my VTOL plane auto-landing above an obstacle(like a tree).
1. Is it possible to switch to QHover mode to hold the height and move the plane horizontal by joystick? I try doing so but my plane keep moving backward after switch to QHover mode.
2.Since the “abort landing” button doesn’t work, maybe recompile the mission planner and add an “pause landing” button could be a possible way?
Posts: 1
Participants: 1
@ardisd wrote:
While testing RLT, Smart RTL and Waypoint Navigation I discovered that the Speed was set to about 2m/s and I could not get it to go any faster despite RTL_SPEED and WPNAV_SPEED both being set to 700 cm/s. Below is links to logs and parameter file of an RTL Test
Thanks
David Ardis
Posts: 1
Participants: 1
@jace26 wrote:
We’ve been using 3.8.5 for some time and have always had issues with VTOL navigation, including it resulting in some wrecks due to odd behavior. We are considering moving up to 3.9.4 because of some interim improvements on the VTOL controller (per the release notes, not sure what exactly) but running SITL shows some of the same terrible behavior.
observed behaviors:
when in MC mode the ac will hesitate at a WP, sometimes holding there for just a second, sometimes minutes before advancing to the next WP. This is preventing us from doing an angled climb out in VTOL after the initial VTOL_Takeoff.when executing a vtol_takeoff followed immediately by a vtol_land, if the vtol_land position is behind the ac’s current position the ac will yaw while moving in a semi-circular path toward the VTOL land position and landing with a random heading. Note: I have no wind on in SITL Also, this has been observed IRL as well. QRTL (either directly commanded or via an RTL command) does the same thing when home is behind the ac and it is in MC mode.
When navigating in MC, particularly right after detransitioning back from plane, the MC will try to reverse course when reaching a WP drawing out a little spiral, but then settle down, and then resume track to the next WP. This is preventing us from making an angled approach to land.
The loiter time and loiter alt WPs seem to not work at all, at least I haven’t figured them out. These seem to basically just send the AC off into the wild (I do have q_guided enabled)
Posts: 3
Participants: 2
@jace26 wrote:
I’m having trouble figuring out turns in Auto. The aircraft always just goes right to the Lim_roll_cd, regardless of where the next WP is. Is there any logic about shallowing out wider turns?
It also seems to always overshoot, despite having a WP radius of 200m, the aircraft always drives into about 110m to make a 90deg turn at 26m/s and always overshoots (lim_roll cd = 2500 cdeg) is there a way to tune this?
I would also like the ability to turn off xtrack correction, sometimes I want to maximize my straight leg in a small field, and end up spending half of the length correcting back to course after overshooting (see above)
There is also no apparent wind correction, steepening turns with a tailwind and shallowing going into a headwind, turing early with a cross from inside the turn, or turning late with a crosswind from outside the turn.
Posts: 2
Participants: 2
@igor23 wrote:
I
![garmin]()
![Sem%20t%C3%ADtulo]()
I’ve been trying to use my Garmin Lidar V3HP with my pixhawk 2.1 via I2C and it worked for a few minutes when it was conected like recommended in Ardupilot.org (picture) but after I turned the system off I couldn’t get any data from it anymore. To check if the lidar was working I used an Arduino and it worked fine with it but never with my Pixhawk. I also tried to get a read via PWM also unsuccessfully. After checking that the sensor was working I tried to use pull up resistors like recommended in Garmin’s manual (picture) but it didn’t work too. I also tried to invert the SCL and SDA cables position in the conector. I’ve been using a life battery (6,6V) to power the sensor. To check if it could be an over tension issue I also tried with a 5V BEC which also didn’t work.
The parameters set in mission planner were like recommended (pictures). I also tried every single type in the parameter RNGFND_TYPE.Does anybody have any ideia of what could be happening?
Posts: 3
Participants: 3
@mxin wrote:
Hi, I’m using QGroundControl and have my simulated vehicle (Dronekit-SITL) connected via TCP:5760. When arming and disarming, the message displayed with weird characters. Does anyone know this problem? Thanks!
Posts: 2
Participants: 2
