bringing in the F3

[dschin]

lilviz:  I am going to start working on your F3 port.

Two major issues that I think we can start to address while waiting for directory reorganization.  1) you don't seem to be reading the mags, have you done anything on that?, 2) getting a telemetry port, is that mostly just a matter of an external wire to usb voltage sensing pin?

[Lilvinz]

1) you are right, the pios_lsm303 driver needs some work to support the mag
2) either put a wire to vsense or find another way in software to distinguish between usb host connected and not connected

[Lilvinz]

Actually the lsm303 driver is completely independant of the used processor.

[Menno]

Hi Vinz,

I believe that I have read somewhere that the implementation of the lsm303 driver into the FlyingF3 port was completed. Can the magnetometer readings already be used int GCS. I can only find calibration settings for the Revo board in the UAVObject Browser.

Right now I get about 360 degrees of clockwise drift every 200 seconds on the PFD compass. Is this normal?

[Menno]

So I have an 'old' Holux GR-213 20 channel Sirfstar III GPS laying around. It outputs CMOS TTL and RS232 at 4800 bps (NMEA protocol). I was curious whether I could get GPS data visible in the GCS. Should this be possible with this GPS. I have pin 3 from the mini din connector connected to PD9 of the F3 board (UART3/Mainport) but no matter what I try there is no data coming in. Just a red cross in the system health graphic.

[Kenn Sebesta]

I don't think the GUI side has been updated to handle the new boards. Right now we have to update the GUI for each new board, which is maintenance intensive. eduoard has been hard at work on dynamic board registration, and this will help somewhat. 

As for the yaw, 1.5deg/s of drift is reasonable if there is not correction via a magnetometer (or other absolute heading reference). 

[peabody124]

So here you go, I think this should address some of your concerns about the F3: https://dl.dropbox.com/u/6645063/AboveGroundLabs-20130103-4a72565b-install.exe

- Fixed the bug where the 6 point calibration was not saved.

- Fixed a bug where the gyro bias wasn't applied (hence the higher than expected drift you observed)

- Made the mag be used to track heading (try increasing the value of AttitudeSettings.MagKp if you are seeing drift.  Please report back how this works).  

- Enabled TxPID (untested!) and Autotuning

You will need to set and save the HomeLocation for this to be applied.

Also Kenn the UI will be automatically generated for the boards.  E.g. Flying F3

Also notice Pt's cool new alarm gadget at the bottom - although it doesn't show much cause no alarms :)

Menno - GPS is disabled in this build.  Once https://github.com/PhoenixPilot/PhoenixPilot/pull/150 is merged I'll look at the GPS support.  But your 4800 bps NMEA should work.  I wouldn't try running the EKF though.

[peabody124]

Small bump: https://dl.dropbox.com/u/6645063/AboveGroundLabs-20130103-965aa5c9-install.exe this should add GPS support back in.

[Menno]

Wow, it's hard to keep up with you guys.

Has something changed in the bootloader of the Flyingf3. I've tried the new firmware on 2 different boards and both of them don't boot in the CGS. If I load the old firmware on them they boot normally.

[Lilvinz]

Try a chip erase e.g. by using the st-link tools. I think its a problem with settings which may still be on the board.
As for the keeping up, its just a brand new thing and we are in the starting phase so stuff moves quickly.
I expect things to settle a bit (in terms of stability) in a few weeks.

[Menno]

- did a full chip erase in the STM32 ST-link utility

- programmed the latest bl_flyingf3.bin that I know of. It was in the package called: phoenixpilot_next_20121224_000641_e715acf08e_win32.

- opened the GCS and pressed rescue

- flashed the fw_flyingf3-20130103-965aa5c9.opfw to the board

- rebooted both the board and the CGS.

Unfortunately it makes no difference, the board does not boot on my computer (W7 32 bit). If I load the older firmware onto the board it connects to the GCS without a problem.

[peabody124]

Darn I hoped the last version without a few of the other modules would avoid the lockups entirely.  It might be some other upgrade path problem but yeah - try erasing the chip like lilvinz said.  As vinz said we're pushing now to get FlyingF3 working fully so hopefully these fast changes will bring lots of improvements.

[Menno]

I don't know if this helps but I have attached to logfiles. The one with discoveryf3 in the name is the previous firmware that loads successfully in the latest GCS. The one with flyingf3 in the filename does not load in GCS.

It says something about availableDevices total ports: 1 (Tabletpc Key Buttons), available ports 0.   

[Menno]

duh, I just found out why I could not get the new firmware going on my computer. I had to delete the old Flyingf3 usb driver first. After that I connected the board, windows installed the new driver and it works.

I can confirm that the new pin layout (January 11th) for the 8 PWM inputs, and the PWM out 1 to 4 pins work as expected. Further testing will follow. 

[peabody124]

Thanks for finding that!  I'm sure it would have blocked a few people.  For the record can you say how you delete teh old driver?

[Menno]

sure I can. So for people with Windows 7 that had the old Flyingf3 firmware installed and are having problems with the new firmware not being recognized this is how I solved it.

I connected the board with USB and went to control panel / devicemanager. under Human Interface Devices there was a yellow warning sign at the boards USB driver. I deleted the old driver. Unplugged the board and after i plugged the board in again Windows automatically installed the correct driver. The green led on the F3 board lit up and GCS recognized it right away.

I attached a screenshot of the driver. In the screenshot there is no yellow warning sign anymore because the board is working.

  

[Menno]

I loaded Flyingf3 firmware from January 11 on my board. Can it be that the TxPID and the GPS module are not active in this release. Is this set in the firmware or in the GCS files?

I really miss the TxPID module, (although it flies great on the old settings) I tried to film a bit but flying the quad and filming it with my phone is not a great combination. http://youtu.be/W_9AHRa4J7I. Will do this again with daylight and helper ;-)

Compass stays put with the standard value by the way, no more drifting.

[peabody124]

Great about no drift. Which is the 11th? I thought txpid was included as an optional module now in next. Go check ModuleSettings.State and ensured txpid is rnavled .

[Menno]

I downloaded the latest GCS version and now everything works as it should.

- The hardware module displays board specific option.

- The TxPID module works

- GPS gives signal

Also from what I could tell from my test flight is that Atti mode behaves better than in the previous release.

Thanks!

[Menno]

I had to erase the board settings after trying the sensor noise calibration tool and the quadcopter was uncontrollable after that.

So I started from scratch again. The tail was not so locked in as yesterday so I took a look at the compass readings. North is not were it should be and the readings drift a full 360 degrees just like in the previous release where the mag readings  where not used. I have no idea what is going on. I have set the home location and there are values in dataobject magnetometer (see attachment). There is also more drift in atti than yesterday?

Any tips on where to look?

[Menno]

This is a weird problem. I have 2 boards that I both

- erased with the ST-link

- loaded the latest BL file (2013-01-12)

- flashed the latest FW file (jenkins-phoenixpilot_nex+ b43c2ebd)

- deleted / re-installed the USB driver (GCS does not recognize the boards otherwise)

- erased all settings from board.

My spare board has a proper bearing lock and shows no drift on the compass. 

The compass of the board that was on my quadcopter today begins to drifts counterclockwise once connected to the GCS. It knows what North is on initialization but instantly begins to drift.

At first I thought that one of the sensors on the board was broken but if I look in the UAVObjectBrowser / Dataobjects / magnetometer the values do not drift in the way that the compass on the PFD. There are no digits after the comma as in the above image.

Is there anything else to reset in these boards or should I just forget about this board?

[peabody124]

Hmm... on both boards did you set the home location (and save it) and then run a 6 point calibration?  You can export the UAV settings from both for comparison and post them here for us to look at.  Also, remember there is that AttitudeSettings.MagKp term that you need to increase to get a stronger influence from the mags.

[Menno]

I erased all settings on both boards. My spare board has a solid compass with the basic settings. The board I am having doubts about has a drifting compass. Google has problems with the UAV files as attachement so her is a link to them: uavfiles_menno

- my spare board with solid compass on the basic settings

- my quadcopter board that drifts on the basic setting

- my quadcopter board after setting (and saving) homelocation, performing 6 point calibration and level calibration.

Saving the home location and performing the 6 point calibration did not have any influence on the compass. The level calibration did.

What I find most confusing about the GCS at this point is that I do not know what the sensible scales are for the different settings. MagKp is at 0,0001, but what steps should I take increasing the values and where do you stop?

[Menno]

I guess that the Home be values have something to do with the magnetic declination and inclination of my position. Although latitude and longitude are visible in the UAVObjectBrowser.HomeLocation, the Be values are still on zero?

I now have MagKp at 0,005 and there is max 10 degree drift in 5 minutes. I know that is not much, but shouldn't there be no drift, certainly not just in one direction.

[Kenn Sebesta]

That's strange that Be values are 0. You've already set up HomeLocation, so those should be populated at the same time. If no one has solved that by next week, I'll look into it when I get my F3Discovery board on Monday.

[Kenn Sebesta]

I didn't get my boards till yesterday. I created a FlyingF3 (hacked up some instructions on the wiki, too), and gave it a look. 

Problem 1, the HomeLocation.Be=[0,0,0]: On my computer it populates the values when I right click on the map and say "Set home here". When you set the homelocation, did you use the map or did you manually type it in? In either case, could you try using the map again?

Problem 2, the drift: This is 100% normal because you're running the default Complementary filter, which doesn't use the magnetometer. Switch to INSIndoors and you will notice that the problem goes away. You'll also notice that the PFD stops responding because the attitude estimation hangs. I have to look into why this is, I've never used INSIndoors. It might be that it requires some optional modules be enabled. Or maybe it's hanging because there's no barometer.

[Kenn Sebesta]

Update: INSIndoors fails because it expects a barometric pressure sensor, which is not available on the FlyingF3.

[Menno]

I set the home location in the map. James asked me to look whether  ObjectPersistence flashes red when this is done. I will do this when I get home.

It does surprise me that you say that the F3 magnetometer is not used in the default Complementary filter, this is new for me. I got below advice in another topic but I guess that it is not useful at the moment as magnetometer is only used in INSIndoors. How does this work with the Revo. You would expect the magnetometer values to be used in GPS guided flight. 

- For the drift (first how much is it after leveling, I would estimate less than a few deg per min) increase the AttitudeSettings.MagKp term.  You can probably go to 0.01 to get a strong correction.  This will only work while home location is set (I think, although we can relax that) so if it's not saving you'll need to set it while testing (and we'll fix the saving thing).

[Menno]

I also want to mention that compass drift on my board does not stop when I increase the AttitudeSettings.MagKp value all the way from 0.0001 to 0.005. Only the level board calibration stops the drifting. This however does make sense if the magnetometer is not used in the default Complementary filter.

[Kenn Sebesta]

Actually, I'm wrong on the mag not being used. The file's quite big because all the filters are lumped together, so I get lost in it sometimes. However, the mag will not update if it's using bad data, which would be the case if it's not calibrated properly for the location it's in.

[peabody124]

Ok.  So here are the steps I took to calibrate my Flying F3:

1) go to the INS tab

2) run the six point calibration

3) place level on the table and click "leveling"

4) click save on that page (don't worry about sensor noise measurement)

5) go to the map and right click near where you live, select "set home location".  Leave altitude at whatever (and grumble at Kenn)

6) go to the object browser and select home location.  click save.

after power cycling my board shows very little drift.  if you want less drift increase the AttitudeSettings.MagKp term up to 0.01.  The mag _is_ used in the complimentary filter mode if the home location is saved.

[TazBox]

Hi,

I want to update the FlyingF3 to the latest testbuild (2013-01-21). I guess i have an issue with the rescue function. After i hit the rescue button i get the following error message:

Could not enter DFU mode.

 Is this a bug ? or i should do a full erase and rewrite the boot loader for each firmware update ?

[Menno]

Found my problem with saving the home location for the F3 board. It  appears to be a bug in the portable windows build version.

- Setting the Homelocation in the portable build leaves the Homelocation be values at  [0,0,0]

- Setting the Homelocation in the install version does set the Homelocation be values.

I have attached an image of the values after setting the home location in the windows installer version of the GCS.

[Menno]

Normally you would not have to rewrite the boot loader for each firmware update.

However this board has migrated from a Discoveryf3 board to a Flyingf3 board. I have noticed that Windows will remember the board ID and remember it as a Discovery board. In my case I did do a full erase in the ST-Link utility and flashed the latest bootloader. After that I manually deleted the USB driver so Windows would install a new one. Solved my problem. There is more about the USB driver in a post in this topic from january 12th. https://groups.google.com/d/msg/phoenixpilot/kf_BQ7g8qug/pbQy6kY11HYJ

[TazBox]

Thanks for the tip Menno.

[peabody124]

I replicated this on my system and neither versions work properly.  The one producing values are incorrect.  For now I would manually overwrite it with.  Alternatively if you go outside with a gps working and HomeLocation not saved (erase it or save it with set = false) it will get the right values itself and you can bring it inside and save that value.

There is an issue for this now: https://github.com/PhoenixPilot/PhoenixPilot/issues/209

[Menno]

I don't know how to manually overwrite because I don't know what value 1, 2 and 3 stand for. How can I obtain the proper values for my home location?

If I remember correctly getting a GPS fix didn't make any difference in the Be values. I will recheck this at home.

[peabody124]

Those stand for X,Y,Z components of the magnetic field where you are.  To get the real values you can use this page http://www.ngdc.noaa.gov/geomag-web/?id=igrfwmmFormId#igrfwmm .  It should give you something like this:

and we want the north, east and vertical components for 0, 1, and 2 respectively (we should rename those BTW).  If you want to use the units we normally use divide those values by 100 and don't worry about the decimal point.

It will only do it automatically on GPS fix if the "SET" field is not saved as true.  For when I'm flying autonomously I leave that save as FALSE so it always picks up my new home location.

[TazBox]

Hi,

I just have another simple question. I want to use a Bluetooth adapter for Telemetry on UART1. 

 I connected the Bluetooth to USART1 using null modem cable. The BT module is set at 57600 8N1. I can see on USART1_RXI (PA9) data coming from the ground station to Flying F3  but is no response on USART1_TXI (PC5). In the ground station the baudrate for telemetry is set at 57600. I might assume that it can be one of the following problems:

- PA9 is not configured as USART 1 Rx

- PC5 is not configured as USART 1 Tx

- the board does not listen for telemetry on USART 1

If someone succeeded to do a simple telemetry setup with a Bluetooth module please let me know.

[TazBox]

I looked in to source code and noticed that correct baudrate is 115200. I updated the bluetooth module to use this baudrate and the GCS telemetry speed. 

The problem is the same, the link is not working. It's not clear for me if PA9 is Rx or Tx. I use the 2013-01-21 build. It's a small mismatch between the pins described in the xls and the FlyingF3/pinout.txt.

[Lilvinz]

The pinout.txt should be right. The mismatch is probably because of one the uarts has rx and tx pins swapped in software.

[TazBox]

What confuses me is the fact that I swapped rx with tx wires and same issue. I guess is an additional small step to make it work but i can't figure it out.

[Lilvinz]

You have to have usb unpulgged for uart telemetry to work. Also have you tried another uart?

[TazBox]

Hi Lilvinz,

The BT module is conected without usb telemetry. I also checked the BT module with a FDTI cable ( USB to 5v TTL).

I tested with 57600 and 115200 bps on USART 1 and USART 2 with BT module and FTDI cable both with null modem and straight connections.

Non of the above combinations worked for me :(.

[tacitapproval]

I have also been trying to get bluetooth working on the F3. I have tried the same things, with the same results, just to confirm.

I have also encountered another odd problem that I haven't been able to track down yet. I am using cppm through a Frsky receiver. For the most part, this works well, but twice I have lost receiver input at startup for no obvious reason. I am also not sure what works to restore it, but control has returned both times, after some combination of power cycling and futzing on GCS. Sorry for the lackluster bug report, I will try to get more definitive information the next time it happens.

On the positive side, the problem I was having with the original Open Pilot F3 port and GCS configuration changes under full-power necessitating esc recalibrations is gone. So, nice job on that one Vinz.

[RC Flyer]

I have the same experience with the same results.
I tried to connect BT module to UART3(Rx=PD9, TX-PD9)
I tried 57600 and 115200 - no connection.
Terminal SSP work fine between computers, so link is ok and transparent.
I also tried UART1,2,3 with FTDI USB to UART adapter - don't work.
As I understand the issue with switching USB to serial telemetry was because the board does not have sensind input to see if USB is connected.
Therefore telemetry was set to USB permanently.
Recently Menno mentioned that this problem was solved somehow.
I am just guessing that we still have this issue......

[TazBox]

Hi tacitapproval ,

I found on internet some references related to FrSky and CPPM. Make sure you have the latest firmware on your FrSky devices. See the links below:

http://diydrones.com/profiles/blogs/why-frsky-cppm-signal-is-so-disappointing

http://diydrones.com/profiles/blogs/frsky-s-cppm-at-27msec-firmware-update-with-ft-prog-and-ftdi-cabl?xg_source=activity

[Kenn Sebesta]

I actually wouldn't upgrade the FrSky hardware, unless you are sure you'll want all 8 channels. The switch to 27ms slows down your control output by 50%, which is noticeable for some people. See my comments in the http://diydrones.com/profiles/blogs/why-frsky-cppm-signal-is-so-disappointing thread.

[Lilvinz]

After that big pin change i have not had the time to test everything. But i will do so on the weekend. It may very well be mistakes in the firmware.

[tacitapproval]

I am aware of the issue with the 18ms rate and have actually flashed the 27ms firmware (although, I wasn't aware of the concern about lag, Kenn. I haven't noticed any difference personally, however). I don't think, though, that these issues would have to do with the problem I have experienced on the F3. On the occasions it has happened, Tx input is completely non-existent, complete with a warning message about manual control in GCS. 

[TazBox]

Thanks for sharing Kenn

[Menno]

I will try what the BE values are with a GPS lock. To see whether I am getting the correct values can you check if this is correct for my home location?

[0]  190

[1]  2

[2]  452

[peabody124]

That looks pretty sensible.  Also I think this build https://dl.dropbox.com/u/6645063/TauLabs-20130127-a095362e-install.exe should fix the bug you were seeing and let you set it through the map.

[Menno]

I installed the 20130127 build on my Windows computer. Below is a screenshot of the Be values after setting the HomeLocation on the map. I guess they look fine so thanks for the update!

[Menno]

Nice. I had the board on the table for 15 minutes and there is no drift whatsoever.

[peabody124]

Woohoo

[peabody124]

For both?  Didn't you have different behavior for both boards?  Also can you confirm that it faces the right compass direction and what your AttitudeSettings.MagKp is

[Menno]

I did a 6 point calibration on both boards followed by a level calibration.

- my spare board holds compass with a MagKp of 0,001. I think this board is well calibrated and needs little input from the magnetometer to hold its heading.

- the board that was on my quadcopter has bigger drifting problems. It will absolutely not hold compass with 0,001. This board needs as much as 0,2 MagKp to get a noticable influence on the heading. It might hold on 0.1 but it will not return to the right heading with that value.

Seeing the big difference in values between the 2 boards it makes me wonder whether the value on my spare board is high enough to get corrective input from the magnetometer?

Anyway I did a test on my quadcopter board. I set MagKp to 0 so it would drift. When the compass drifted 45 degrees of the right heading I increased the MagKp value and measured how long it would take to get back to the right heading:

MagKp 0,2 (3 minutes and 20 seconds for 45 degrees)

MagKp 0,3 (1 minute and 55 seconds for 45 degrees)

MagKp 0,5 (50 seconds for 45 degrees)

Hope this helps.

[TazBox]

Hi,

I guess i also have a drift problem. Almost always my quad tend to move left. At the beginning it moves slowly but if i do not compensate from the transmitter sticks it accelerate in that direction. 

I did not change any parameter in stabilization tab, i use only the default values.

Do you have any hint ? 

[Menno]

Can anybody tell me what the side effects from a to high MagKp value are going to be. Is it going to suppress the Gyro signal in such a matter that stability will suffer from it? There is bound to be a down-side to this otherwise we can just boost the value to 1?

[Kenn Sebesta]

That's not the drift problem from the magnetometers. Here, you have a drift problem where your vertical axis is not corresponding with what the vehicle thinks is vertical. Since the quad has no absolute position sensor (aside from your eyes!), it cannot correct for that kind of positional drift.

[Kenn Sebesta]

The downside is that the noise from the magnetometers is going to be more strongly propagated through the system. This means more of the magnetometer signal and less of the gyroscope signal will be used for attitude estimation. So at a certain point, you probably can't fly any more. And heaven help you if you get close to a source of magnetic interference, such as iron or a current conducting line!

[Menno]

So what would be the highest sensible value for MagKp. I think standard value is 0,001? On one of my boards it holds heading with this value just fine. The other board needs a 0,1 value however to hold its heading.

I have also done a test on both boards. I set the MagKp value the the lowest possible 0,00000001.  At that value the boards heading starts drifting. After that I increased the value to see where the compass would return to its original heading. Both boards need a value of at least 0,15 to return to the correct heading.

[peabody124]

The problem with high values is that you'll start to get noise in your heading from the mag and become succeptible to external fields.

0.1 seems really too high and I'm puzzled what is up with this board.  Can you take a screenshot of the scopes?  After you run leveling and save the results is the Z gyro near zero?  Is it the same after you unplug it and plug it back in again.

[TazBox]

Hi,

I had a similar yaw rotation drift problem on a board that used MultiWii. The issue was then because the board was to close to the engine power distribution board ( i use a DJI Naza clone). The magnetometer should have at least 5-6 cm from the power distribution board.

[Menno]

These are the results with Board1 (with high drift). Test is done with just the bare board, no airframe. I pointed the board to the North (more or less)

after level calibration, MagKp at 0,01;

Board 1 after reboot, MagKp still at 0,001;

Board 1 after reboot, MagKp at 0,3;

[Menno]

Here is Board2 after level calibration, MagKp at 0,001

And Board2 after reboot, MagKp at 0,001;

[Menno]

I can't edit my messages: The picture is with a MagKp of 0,001

[TazBox]

Hi guys,

I used Autotune to get the PID value in the air. It's just great. It works nice. I try to understand now  why do i have slightly different values for Roll and Pitch ? 

Is it because the battery is not symmetrical on all axis ? because the rest of the quad is symmetrical. The battery has about 450 grams.

[peabody124]

Menno: I think what you are seeing falls within pretty normal sensor variation.  With CC3D (no mag) I wouldn't consider 7 degrees in a minute outside the normal variation at all.  It seems like with both a magKp of 0.01 is enough to stabilize it so probably will be ok.

One other thing you might want to check (sorry for jumping you through so many hoops) is see how it looks after arming then waiting 2-3 minutes (so the scopes stabilize) at make sure the longer term behavior is good.  The arming should re-zero the gyro and make it snap back to north.  Try this with a MagKp of 0.01 for both.  Also try and face it close to north so the attitude traces are all near 0.

[peabody124]

TazBox: Great to hear of another AT success.  It probably is because of the roll/pitch asymmetry   I consistently see lower values in the axis my batter faces.  There's also a degree of noise in the measurements - it runs for longer now to lessen that but will still produce slightly different results each time (and even depending on your battery voltage).

[Menno]

I would not exactly say that the boards snap back to North when armed. On board 1 (the one with the higher drift) the drifting slows down to about 3 degrees a minute with MagKp at 0,01:

On board 2 the drifting comes to a stop after arming it (MagKp also at 0,01):

[peabody124]

It's still odd to me.  Can you record a 5 minute log with the worse board?  Tools->Start logging.  Upload it somewhere and attach a link (and mention your GCS version) and I'll look at it.

[Menno]

Do I need to arm the board or do anything else (board 1 is not mounted at the moment).

[Menno]

here is a logfile. 

This is board only. It's not connected to anything but the USB cable. I let it rest for 5 minutes and then I set the status of the board to armed and let it rest for another 5 minutes.

[peabody124]

Ok. Curious.  

[peabody124]

Sorry clicked post.  Curious - the gyro error seems to average 0.06 deg/s which matches the 40 degrees of drift you see.  The gyro bias is very slowly moving to correct that but that term is way too low.  Can you try this firmware: https://dl.dropbox.com/u/6645063/fw_flyingf3-menno.opfw

[Menno]

Hmm, may I ask what's different in this firmware file. Drift certainly seems to be a lot less. link

[peabody124]

There was a correction on the z-axis that wasn't meant to be there.  It was the only thing that could explain the persistent bias.  If that works for you I'll make a pull request.

[Menno]

I don't know. Maybe I should just scrap this board. It persistently has more drift than my other board.

I connected the board again today to look at the scoops and there is an almost constant 20 degree per minute drift on the attitude yaw.

The strange thing is that the Magnetometer values in the UAVObjectBrowser.DataOjects don't show this drift. I need a MagKp value of 0,2 to get some really noticeable influence on the the attitude yaw. Level calibration does help a bit but I can't imagine that it is necessary to perform this on a daily bases.

[peabody124]

So that change didn't help on a second test then?  I wouldn't scrap it - just hold onto it for programming/testing etc.  Maybe we'll find find a bug too.  I do find it odd though - arming should really help re-zero the yaw gyro.

[Menno]

Can the board status be of influence on the zeroing of the gyro. There is no rx connected at the moment. Arming was dine in the gcs.