@semo wrote:

Hi all ,

I have Pixhawk flight control when I connect it to my laptop by cable using MP

it connect well but after the connection the MP try to get the parameters from the device but it couldn’t get it

the dialog of getting param not able to read the param . and keep on screen

the Firmware is arduplane But I don’t know what is the release

I need to get the parameters coz It has the final param setting , I don’t want to lose it .

after connection it show in the HUD the moving of the device , no problem in the device

, maybe there is any setting that prevent the MP from reading the param ??

maybe the parameters set in another programs such as tablet ( Tower , or other software ) dose it effect ?

any help please
Regards.

Posts: 3

Participants: 3

Read full topic

@ecabanas wrote:

Hi all again,

Today I tried to put my skid rover into auto mode and it has been a disaster again.

First of all: in manual mode forward and backward goes perfect, but when it turns left turns ok, but when It turn right the rover makes a reverse throttle…very strange, better see the videos.

Later I just tried the auto mode, a straight line to waypoint 1, pointing to the north and the rover went to the east without any sense

I attached some videos and the logs
Turn problems: https://www.dropbox.com/s/eg7fgezefucksba/turn%20problem.MOV?dl=0
Auto problem: https://www.dropbox.com/s/eb46p9ojrlj4wi2/Auto%20mode%20error.MOV?dl=0
LOG: https://www.dropbox.com/s/sqxwovwo2ycc1uq/00000001.BIN?dl=0
Thank’s for your patience with me.

Best

Eduard

PS: if you come to Barcelona you have invited a paella

Posts: 2

Participants: 2

Read full topic

@Carpette_Stunt wrote:

Hello everybody,

With my 450 Walkera where I put a 2.8 APM with 3.2.1 firmware, i can’t start the maint rotor motor.

I’have all the input working and I can see them on the radio calibration page. Then I can arm the motor but when I arm it the esc make the 2-3 little sound and try to turn the engine (like the initialization) but nothing more. I have the collective pitch who work but never the motor start (the motor is on the CH8 out).

And is that possible to make a switch like an Idle up? I see severals video on youtube with that but I can’t found any functions on mission planner…

Thank’s for any help!

Have a nice day!

Posts: 1

Participants: 1

Read full topic

@Diego_Rivas-Lazala wrote:

Hello, everyone!..Once again. I need help with my skid steer rover because the mission planner shows that the vehicles can go into auto mode but the rover doesn’t move while the mission is being “executed” as stated in the messages tab of the flight data. The only movement I can receive other than perfectly being able to drive the rover in manual is if I hit RTL on the flight data screen, but if RTL is in the mission the rover doesn’t move at all. One issue is that when I do hit RTL the rover just goes in a circle nonstop. I’m running a 6 wheeled skid steer rover with a sabertooth 2x12 (dip switches set to upside up [DUUDUD]) and on ardurover 3.5. Looking for any advice! Please!
Here are my parameters and data flashlogs from earlier today when: https://bergenorg-my.sharepoint.com/:f:/g/personal/dieriv21_bergen_org/EgEUe6Db_NNBvPf4Eb1QGAcBalY1w19061I__u_ZlWZVkA?e=caYXAY

Posts: 2

Participants: 2

Read full topic

@glacier051 wrote:

Hello:

Having a frustrating time getting this quad not to flip over backwards on T/O. The thing is, it was flying fine until I partially disassembled it for transport, removing the props, folding in the arms and lowering the VTX and GPS masts – no wiring disconnects. The only thing between then and now is I added some trainer mix lines, which I have removed.

The quad is running V3.5.7.

Things I’ve checked:

-Correct props on motors

-Motors turning in correct direction and appear to have the same RPM at idle ( motor test correct )

-calibrated accelerometers, gyros and compass for the new location

-no messages indicating any failure

-ESC (Lumenier 4 in 1) wiring secure – ran the Mission Planner ESC calibration

-Cube is facing it the correct direction and the AHRS orientation parameter is 0.

-Good C.G. within 2mm of center.

-No odd Taranis mixes throwing in back ELE

This frame normally lifts straight up once the RPM comes up. Any tips are appreciated.

Ron

Posts: 1

Participants: 1

Read full topic

@CraigElder wrote:

**Issues & Pull Requests"

GSOC
*Update

Plane
*Update

Copter

Rover

Posts: 1

Participants: 1

Read full topic

@bnsgeyer wrote:

I’m pleased to announce that hopefully in the next week @ChrisOlson and I will be releasing a version of ArduHeli 3.6 with L1 navigation including its own speed controller. The way it will work is that you will have a parameter called WPNAV_USE_L1_NAV. if it is set to zero then the standard copter navigation will be used however if set to 1 then the Plane L1 navigation controller is used for only Waypoint, Loiter Unlimited, Loiter Turns, Loiter Time and Land. For all other commands in your mission plan, it will smoothly transition to/from copter navigation controller. In the vertical axis, it still uses the copter position controller and performs linear altitude changes between waypoints just like copter nav however if the heli doesn’t have the climb performance or the climb rate is limited, then it doesn’t slow down to make the altitude and will fly through the waypoint at speed and continue climbing as it navigates to the next waypoint.

Here are the parameters it uses
WPNAV_USE_L1_NAV - enables/disables L1 navigation
WPNAV_L1_LTR_RAD - radius used in loiter mode. aircraft always flys clockwise around loiter point
WPNAV_ACCEL - set max acceleration in x axis. Initially use 100. it will provide smooth accel/decel.
WPNAV_SPEED - sets default speed for wp navigation
WPNAV_ACCEL_Z - set max vertical acceleration
WPNAV_SPEED_UP - max climb speed
WPNAV_SPEED_DN - max descent speed

L1 parameters
NAVL1_DAMPING - same as Plane L1 parameter
NAVL1_PERIOD - same as Plane L1 parameter
NAVL1_XTRACK_I - same as Plane L1 parameter
NAVL1_TURN_SF - scale factor for coordinating turns. The L1 nav includes an input to the pedal to coordinate the turn. If you think it is not enough or too little, this scale factor allows you to adjust it. Start with the default value of 1.0 and recommend only changing by 0.05 increments if you think you need more or less.

Speed control parameters which are standard PID parameters. Use the default values initially. The FF value is important for reducing transients when starting L1 nav with some speed on the heli.
SPDHGT_VEL_P
SPDHGT_VEL_I
SPDHGT_VEL_D
SPDHGT_VEL_IMAX
SPDHGT_VEL_FILT
SPDHGT_VEL_FF

We will let you know when it is available for download. I’m sure Chris will also add some posts giving his experience with it and tips for using it.

Posts: 2

Participants: 2

Read full topic

@Dinesh_Sathia_Raj wrote:

After updating to the latest version of Mission Planner, every time I run the program, within a minute of starting I get this error.

I’ve tried uninstalling and reinstalling and using an older version of MP. The problem persists. Any help would be great.
Thanks in advance.

Posts: 1

Participants: 1

Read full topic

@Willem_van_Zyl wrote:

Hi,

I installed the new version 1.3.66 (First time user, new install) and the app crashes on startup. Any help?

Only information I get from the Windows Crash is:

Problem signature:
Problem Event Name: APPCRASH
Application Name: MissionPlanner.exe
Application Version: 1.3.66.0
Application Timestamp: 5cc1a5d3
Fault Module Name: StackHash_8468
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: PCH_68_FROM_ntdll+0x0000000000090D0A
OS Version: 6.3.9600.2.0.0.256.48
Locale ID: 7177
Additional Information 1: 8468
Additional Information 2: 8468af064a6ccc5d71687fdf1d443734
Additional Information 3: ae02
Additional Information 4: ae02c99d42f1bf08aaf97ece90e97ef9

I’m running Windows 8.1 on a VMWare 10.0.7 build-2844087

Posts: 1

Participants: 1

Read full topic

@tegwin wrote:

A bit of searching on here and I have drawn a blank.

Does anyone know of any BMS boards that interface with Ardupilot over CAN or SMBUS?

I would like to build some 4S and 6S “smart” packs.

Alternatively can packs from the likes of Yuneec be used? Not sure what protocol they use?

Posts: 3

Participants: 2

Read full topic

@Oli1 wrote:

Hey all,

since my clone Sparky2 has its compass mounted backwards and a few other quirks that shouldn’t be there, I don’t really like the idea of it taking some 100s of dollars into the air.

Looking for a replacement, wanted to get an Omnibus F7 V2, but it seems like they’ve been superseded by OmniNXT F7. They’ve got a different target on Betaflight, so it’s not just renamed.

Is it planned to support the OmniNXT F7 in Ardupilot anytime soon?

Cheers
Oli

Posts: 4

Participants: 3

Read full topic

@tridge wrote:

This is a followup to the post from yesterday which compared a uBlox M8P and a uBlox F9P without external corrections. In this post I will compare the same two GPS modules but this time I have supplied high quality RTCM 3.2 correction data from a local NTRIP server (2.9km from the test location at my house).
The RTCM was injected using MissionPlanner to connect to a free NTRIP server that is part of the auscors network. Similar services are available in many countries all over the world.

image.png1176×418 70.8 KB

Using MissionPlanner makes using an NTRIP server extremely easy, and the results are very good if you have a server close to the location where you are flying. The specific auscors server I used for this test was SYM14.
A NTRIP server works by providing access to realtime RTCM correction data from a high quality GPS base station, the same data you would get if you setup your own RTK base station, but much easier to use and avoiding the need to buy a separate RTK capable GPS to act as the base.
For this test I used the same test position as location 3 from yesterdays post. It is a location in my back yard, with moderate tree cover.

I chose this location not just because it is convenient for me (although of course it is!) but also because when I’ve previously done RTK tests I know it is boring to test a location with clear view of the sky in all directions. In such an ideal location RTK does extremely well, and you get constant results within a few centimeters no matter whether you use a newer dual-band GPS or an older single band GPS. What is much more interesting is to test how well the newer GPS performs when it has some significant signal obstruction and a few multi-path opportunities off buildings.

Test Setup

As for the tests yesterday, the GPS modules used were:

• Drotek UBlox Zed-F9P with dual-band antenna
  – https://store.drotek.com/rtk-zed-f9p-gnss
  – https://www.csgshop.com/product.php?id_product=265
• Hex Here+ GPS (based on uBlox M8P)

The two modules were connected to the same Hex CubeBlack running ArduPilot, with the M8P GPS as GPS1 and the F9P as GPS2.

Gaining RTK Lock

I deliberately ran the modules for 40 minutes without the RTK corrections to see how they were performing on the day and check it was similar to yesterday. Then I enabled RTCM data from the NTRIP server for nearly 5 hours before disabling the RTCM corrections for 20 minutes at the end to see the effect of removing the corrections.
You can see the whole test here with the altitude measured by the two GPS modules over time.

image.png1020×530 34.2 KB

The left hand axis shows the AMSL height in meters. The right hand axis shows the GPS status, where 3 is an ordinary 3D fix, 5 is a RTK-Float solution and 6 is a RTK-Fixed solution. A value of 4 indicates a SBAS solution (that didn’t occur in my tests), but can also indicate a very poor RTK solution.
There are a few striking things in this graph:

• the time when RTCM corrections are first supplied is extremely clear, with the altitude solution becoming a lot more consistent very quickly (within a few seconds). You can see that the F9P GPS goes to a RTK-Fixed solution immediately, whereas the older single-band M8P gets a less accurate RTK-Float solution.
• after 20 minutes both GPS modules briefly go back to normal 3D fix. I suspect I had a short network outage at that time causing the RTCM stream to stop. More on that later.
• for most of the 5 hour test the F9P kept a RTK-FIxed solution, whereas the M8P only occasionally managed a RTK-Fixed, but did keep a RTK-Float solution.
• when I disable the RTCM stream at the end of the test the accuracy reverts to normal 3D fix levels one minute after the RTCM stream stops (both modules revert at the same time, indicating they must have the same internal timeout).

Now for the horizontal accuracy:

image.png1016×514 39.6 KB

On the left axis we see the horizontal error in meters. On the right axis we have the GPS status (same as above). The improvement in accuracy of the F9P dual-band over the M8P is extremely clear both for the portion with a RTK fix and for the part without RTK.

RTK Fix Accuracy

Lets look more closely at the parts where both modules had a RTK fix. First altitude:

image.png1029×529 50.5 KB

and now horizontal error:

image.png1016×533 40.7 KB

For altitude we see the F9P changes around +/- 10cm whereas the M8P changes over about +/- 30cm.
The difference in horizontal error is even clearer. The F9P averages around 3cm horizontal error with a max deviation of 10cm. The M8P moves by about 1 meter.
I should note that the exact “correct” position was obtained using the 5 hour average of the F9P position as I don’t have any way to survey it any more accurately. It is quite possible that it had a systematic error, so really we can only infer how much movement we see from these results rather than absolute error. It is very clear that the F9P gets a much more consistent position than the M8P does.

RTCM Outage

The short network outage gives us a nice example of what happens if you stop feeding your RTK GPS the correction data it needs. It will keep a pretty good lock for about one minute, then revert to a normal 3D fix (or possibly SBAS fix if there is a SBAS satellite in view). This is one disadvantage of using a NTRIP service - if you have your own RTK base GPS then you are less likely to get an outage.
Let’s look at what happens on the outage with altitude:

image.png1038×528 39 KB

On the outage both GPS modules revert to a 3D fix and their error immediately jumps up to the meter range. When the RTCM data is restored it takes nearly 14 minutes before the F9P gets a RTK-Fixed solution again, but it does get a RTK-Float solution quickly.
Now the horizontal error:

image.png1015×522 50.1 KB

On loss of RTCM data we go to a 3D fix and the error jumps to over 1.5 meters. When RTCM data is restored we get a RTK-Float solution and error on the F9P quickly drops below 1 meter. After 14 minutes we get the RTK-Fixed solution on the F9P and the error drops sharply to a few centimeters.
So if you are relying on RTK GPS for precision landing then you really need to ensure your correction data stream is reliable. If what you are trying to do is mapping then using post-processed PPK is likely to be much more reliable.

GPS Reported Accuracy

Another important piece of data that a GPS gives you is the reported accuracy. A uBlox GPS will tell you the estimated accuracy in vertical position, horizontal position and velocity. These numbers matter as they are used for GPS blending weights in ArduPilot and inside the EKF (influencing the weighting of the GPS).
The uBlox has always been known as an “optimistic” GPS, with reported accuracies much better than what it actually achieves. I was interested to see if the F9P was the same.
Here is the reported horizontal and vertical accuracy for the uBlox M8P over the whole test.

image.png1014×519 54.9 KB

On the left axis we have horizontal accuracy in meters (in red) and vertical accuracy in meters (in green). The number of satellites is on the right hand axis in blue. During the non-RTK part the claimed accuracy is a bit optimistic, by about a factor of 4x. This is common for a uBlox M8. Once it gets a RTK-Float solution it improves the claimed accuracy down to around 1 to 2cm, which is wildly optimistic given the solution varies by about 40cm.
Now the F9P:

image.png997×518 55.5 KB

The F9P claims accuracy of about 70cm vertically and 40cm horizontally when it doesn’t have a 3D fix. This is optimistic, but not quite as bad as the M8P. Once it gets a RTK-Fixed solution it claims an accuracy of 1cm, which isn’t far off in absolute terms from the real horizontal accuracy of around 3cm, but is still off by 3x as a multiplier. The lesson is that GPS reported accuracies need to be looked at with scepticism.
If we just look at the part of the data where the F9P has a RTK-Float solution you can see the optimism is as bad as the M8P. It reported both horizontal and vertical accuracies of around 5cm, but was off by about 60cm horizontally and over a meter vertically.

Speed Accuracy

The final accuracy that is reported is velocity, which is reported in ardupilot as GPA.SAcc (speed accuracy).
Here is the reported speed accuracy of the two GPS modules in m/s:

image.png995×508 39.5 KB

Interestingly the F9P reports around the same speed accuracy no matter what fix type it has, whereas the M8P claims much better speed accuracy when it has a RTK-Float fix.
Despite being less confident of its velocity estimate, the F9P did produce better results for speed. Here is the reported speed for the M8P in red and F9P in green (in m/s):

image.png1013×522 61.8 KB

The F9P is clearly producing less noisy speed estimates which should translate into better position hold performance.
For vertical speed the F9P also wins, but not by as much:

image.png1014×537 79.2 KB

Conclusion

The uBlox Zed-F9P is as big an improvement for RTK as it is for uncorrected positions. I suspect it is going to be very popular for anyone wanting precision flight.

Posts: 2

Participants: 2

Read full topic

@JulianZ wrote:

Hi
I wanted to test the new magnetometer RM3100 from Drotek. I’ve read all the threads about it and as far as I understand it should work with 3.7-dev - unfortunately I can’t get it to work, moreover there is no RM3100 checkbox in COMPASS-TYPEMASK parameter.

Any ideas?

Posts: 1

Participants: 1

Read full topic

@Peter_Weichhart wrote:

I know that I have a very unique setup. But is this not what makes our hobby so interesting?

Before I start to explain the actual problem I like to share some of my details:

Environment:
Frame Type: Dodeca Hexa (12 Motors)
Flight Controller: Cube Black (003E0028 33375100 37353832)
Firmware: ArdoCopter V3.6.6 (6b88b2ba) (I am not running the latest version because I had an issue with the compass calibration on V3.6.7)
System: ChibiOS: d2030d88
Software: Mission Planer 1.3.66
ESC: 12 x Flier Air (Opto)
Remote radio: Self build. Joysticks are converted via a ppm to pwm converter

Description of Connection:
As I am working with “Opto” ESC’s I have to power pin “7” of the FC (Cube 2.1) as per manual with 5V. What I did with a separate BEC.
6 ESC’s are connected to MAIN1 to MAIN6 the other 6 ESC’s are connected to AUX1 to AUX6.

Problem Description:
Before I powered pin “7” of the FC with 5V via a separate BEC the motors wasn’t working at all.
After powering pin “7” with 5V and performing a motor test I have the following effect:

Motor1 on MAIN1: Working perfect as expected
Motor2 on MAIN2: Working perfect as expected
Motor3 on MAIN3: Working perfect as expected
Motor4 on MAIN4: Working perfect as expected
Motor5 on MAIN5: Working perfect as expected
Motor6 on MAIN6: Working perfect as expected

Motor7 on AUX1: Do not respond at all
Motor8 on AUX2: Do not respond at all
Motor9 on AUX3: Motor no.9 should run, but Motor no.7 is running
Motor10 on AUX4: Motor no.10 should run, but Motor no.8 is running
Motor11 on AUX5: Motor no.11 should run, but Motor no.9 is running
Motor12 on AUX6: Motor no.12 should run, but Motor no.10 is running

I tested each Motor, ESC’s and the cabling by using a servo tester. With a servo tester all motors are working perfect as expected. Means: There are no faults in cabling, ESC’s or Motors.

I wonder if the AUX connections getting powered from the 5V I connected to pin “7”.

I hope somebody have an idea what could be wrong.

Posts: 1

Participants: 1

Read full topic

@zwadzinski wrote:

Hi, so I am following this guide to setup SITL/MAVProxy on a Linux VM. I am also using this for a plane while the video is using a copter. I can get to here: https://www.youtube.com/watch?time_continue=4&v=pJGFkZmGV6o 19:20 before an error occurs saying:
<<<bash: cd: /home/zwadzinski/ardupilot/Ardoplane: No such file or directory.>>>

image.png774×433 241 KB

I’m assuming its because I am using a plane but have no idea. Also I am very new to this whole thing so dumbing it down may be a good idea. Any ideas on what to do? thanks

Posts: 3

Participants: 2

Read full topic

@rijun034 wrote:

Hi,

I have an issue with pixhawk PDB’s battery pack detection.
I’ve calibrated the module to detect voltage but not current. I’m using a custom made 4S lithium ion pack for my plane and same time I’m charging it with a solar MPPT (It is a solar UAV).

I confirmed that the battery is getting charged during ground tests. But only few times the mission planner shows the battery capacity increasing because of solar power. But after a while it is continuously decreasing the percentage and falling to battery failsafe mode (below 20% i set).

When I check the battery with another testers, it is showing more capacity and when I connected this same battery at after 2 or 3 minutes, again it showed 85 - 90 %.

Battery is getting charged, but this issue is repeating.

Any ideas or suggestions will be really helpful.

Posts: 1

Participants: 1

Read full topic

@TunaLobster wrote:

I am trying to find a way to enable a geofence in SITL without an autotakeoff. Since there is no way to have RC channels pass through I am struggling to find a way to get the fence to turn on. Is there a button in Mavproxy or Mission Planner that I am waiting on?

Posts: 3

Participants: 2

Read full topic

@semo wrote:

I couldn’t found the tower app for android ??

what is the problem ?

Posts: 4

Participants: 3

Read full topic

@RsX88 wrote:

Hi all
i have a 3DR pixhawk and i had a crash with my quadcopter after upgrading to 3.6.9
before this day i had a similar crash on an older version, maybe 3.7.x and i thought it was a faulty esc
after this i changed the GPS with a NEO M8N, the 4x DJI 30A ESC with hobbywing 4 in 1 and the batteries with a pack 10400mAh 3S LiHv (2x 5200mAh)
i did a couple of flights before the crash and run the autotune successfully and a couple of missions with spline waypoints and take off/landing: all perfect
at this point i decided to test how long the quad could fly and fully charged the lipos and put the quad in loiter
i have to admit i soldered the current sensor the other way around, so i had no current measurement and i just monitored the voltage that was very stable during discharging
after 43 minutes the quad had still 10.75V and started doing some twitch every once in a while
at 44 minutes the quadcopter entered in an uncontrolled wobble and went down flipping into the ground
the battery had another 10% capacity
i know i overdischarged it, i was set on coming down at 3.5V per cell, which now i know it is too low
nevertheless i still had another 10% and the voltage was not dipping
i reviewed the logs and i’m not sure what is the problem
there are many errors but they appeared either after the crash or way before the crash (40 minutes earlier)

this is the log https://plot.dron.ee/tWIg

what could be the problem?
thank you

Posts: 2

Participants: 2

Read full topic

@masterpii wrote:

Hello @tridge!

I saw that you were doing quite some work on the parrot disco. Any reason why nobody uses C.H.U.C.K. as a controller for a antenna tracker system? There are a whole bunch of other supported boards. I know many other boards are probably cheaper but i would like to use chuck… Who could add that board to the list of supported boards? How could that be done? it could have the advantage to generate ground wind and additionally directly generate a video-file from ground. That way i always have an additional eye on the airframe. What do you think?

Best,

Peter

Posts: 1

Participants: 1

Read full topic