Test builds

[peabody124]

https://dl.dropbox.com/u/6645063/abovegroundlabs_0.1.0-20121222-3e92a38e_amd64.deb

https://dl.dropbox.com/u/6645063/AboveGroundLabs-20121222-3e92a38e-install.exe

https://dl.dropbox.com/u/6645063/AboveGroundLabs-20121222-3e92a38e.dmg

Just to see if all the rebranding stuff is good.  Make sure no copyright or attribution was dropped inappropriately.

[AlPackin]

nice, Windows build flies fine

[Kenn Sebesta]

Mac app bundle works fine. I can't test the firmware right now, but it seems you and Ed already did.

(Did find this: "Some of this work was contributed under hte". I'm just noting it here for ease of finding it later.)

[peabody124]

Also since I've heard some ramblings, please point out if there are any places where we inappropriately removed copyright to OpenPilot.  As far as I know (and intended) there are ZERO places I removed copyright for OP, including the install for windows.

Kenn, good point about "hte".  I felt like the right thing in the list of authors was to point out the individuals contributed work under both projects which is true.  Frankly, the majority of the code was contributed by individuals who have moved here but it should still be pointed out they did it under the auspices of OP.

[Menno]

hmm, I used the EXE file on my windows 7 laptop (32 bit). I get a warning about the firmware and the CGS not beeing the same version. If I click it away the CGS opens. The only tab that seems to read values is the stabilization tab. All other tabs just give the default values.

[Menno]

This is on the DiscoveryF3 board btw

[peabody124]

Hmm... this needs looking into.  The main thing about this build was to verify the branding was done appropriately and hadn't lost any attributions while making it clear this is a separate release from OP.  I did test the F3 just the other day but not with this particular release.

You did upload the firmware that comes with this installation, right?

[Menno]

No. I was not aware that there where already AGL releases for the F3 board. I'll look into this when I get home.

[Menno]

I see that there are new firmwares in the installation folder of the new GCS. When I try to select the FlyingF3 firmware I get a warning:

[Menno]

It's probably because my F3Discovery board still emulates a Coptercontrol board. So where can I get the FlyingF3 Bootloader files?

Also, is there any way to edit messages. It would keep the treads a bit cleaner.

[peabody124]

I'm on the road right now but will post the boot loader files when I get the chance. I just tested on my f3 and it worked. Do you. Need the .bin file or .elf?

Also we are not using the acronym AGL to avoid confusing an association Rusty. We're discussing the name thing again now.

[Lilvinz]

Here are current portable builds including all firmware and bootloader files for windows, linux and linux64:

https://docs.google.com/folder/d/0B-67-Wk4SPYBeG81Z2FkVGhTTk0/edit

[peabody124]

Thanks Vinz!  This build wasn't particularly intended for flight testing but should be ok.  Just keep your eyes peeled for anything strange and let us know how it goes.

[Menno]

He that's great. I'll try at my own risk ;-) and give feedback on my findings. I have some spare time with Christmas and years ending so this is really welcome. Although weather forecasts are terrible over here. I'm mostly confined to the attic and the wife really doesn't like me flying indoors with anything bigger than a Ladybird.

[peabody124]

Also here is an issue https://github.com/PhoenixPilot/PhoenixPilot/issues/127 for anyone to point out any errors in copyright or attribution.

[Menno]

So here are my first findings with the new firmware FlyingF3:

- The package posted by Lilvinz gave me some problems with missing drivers when I hooked up the board to the CGS. (Windows 7 32 bit). Installing the Exe package posted in the first post on this tread solved that problem.

- The GCS posted by Lilvinz had the Open Pilot logo in the taskbar when I started it up.

- The vehicle setup wizard does not work (this is not essential to get it working).

- The system health check has the event system button displayed in yellow. The debugger gives the following warning: [DEBUG]Warning: Element "PathPlanner" not found in SVG.

- The compass tends to drifts clockwise in a slow constant rate (maybe just my board?). It holds it position after leveling the board with the INS module, but after a short time it begins drifting again.

- I can't save the TxPID settings to the board. First I enable the function and you get a red cross while trying to save (this is normal I believe). Then I powercycle the board and adjust the instance setting and values. This however can not be saved to the board in a normal way. Somehow I managed to save the values after a few times but when I check the Expert tab on the Stabization (shouldn't this be Stabilization?) the values don't change. Normally you should see the values changing when you arm your transmitter an turn the assigned dials.

- Whenever I start the GCS application it asks me if I ant to save changes when browsing throught the output module. No changes are made in the output module however.

Attached is the save file from my board. 

[Menno]

Ok so it flies. On default values the tail of my quad is not so locked in as on the previous OP firmware (rate mode).

Because of the incompatibility issues I am experiencing with FlyingF3 and the GCS this version has not much to offer for users at this stage.

Maybe a decision should be made about support for the F3 board. Are future OP firmwares going to be supported or are there only going to be Phoenix beta releases made for this board. Don't get me wrong, I'm not just beeing impatient and all of your work is highly appreciated, but I think it would be good to get this point clear for users that already have the OP firmware loaded on there boards. 

[peabody124]

Are you having issues with firmware compatibility if you use the firmware and exe from the same bundle (either both from what I posted or what Vinz posted)?  You mean the dialog pops up saying they are incompatible?

The direction going forward is that everything moves into the Phoenix space.  OP doesn't support f3 and made it clear they didn't want to.

[Menno]

There are no compatibility issues prompted when I start the CGS anymore.

I have tried the GCS and the FW combination from Vinz his package and the GCS and the FW combination from your package (which is installed in the programm folder). Both have the same result. The board system health indicator lights the event system in yellow, the debug gadget says something about the pathplanner and the TxPID settings fail to write to the board. 

I have reflashed the board with the previous OP port firmware and everything works fine when I use the exact same setup procedures.

[Menno]

Below is a grab from the debug gadget:

17:54:43[DEBUG]Warning: Element "PathPlanner" not found in SVG.

17:54:59[DEBUG]SMARTSAVEBUTTON Upload try number 0 Object "TxPIDSettings"

17:55:00[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:00[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:00[DEBUG][uavtalk.cpp] Transaction failed 1119015598 0

17:55:00[DEBUG]SMARTSAVEBUTTON Upload did not timeout 0 Object "TxPIDSettings"

17:55:00[DEBUG]SMARTSAVEBUTTON Upload try number 1 Object "TxPIDSettings"

17:55:00[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:01[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:01[DEBUG][uavtalk.cpp] Transaction failed 1119015598 0

17:55:01[DEBUG]SMARTSAVEBUTTON Upload did not timeout 1 Object "TxPIDSettings"

17:55:01[DEBUG]SMARTSAVEBUTTON Upload try number 2 Object "TxPIDSettings"

17:55:01[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:01[DEBUG][telemetry.cpp] Object transaction timeout for "TxPIDSettings" , re-requesting.

17:55:02[DEBUG][uavtalk.cpp] Transaction failed 1119015598 0

17:55:02[DEBUG]SMARTSAVEBUTTON Upload did not timeout 2 Object "TxPIDSettings"

17:55:02[DEBUG]SMARTSAVEBUTTON Object upload error: "TxPIDSettings"

17:55:02[DEBUG]Got ack for instance: 0

17:55:02[DEBUG][uavtalk.cpp] Transaction succeeded 795021530 0 

[peabody124]

Ah, yes TxPID wasn't enabled in the FlyingF3 branch.

Try this version https://dl.dropbox.com/u/6645063/fw_flyingf3_txpid.opfw with the Above Ground Labs version of the software.

Don't worry about those other warnings.  We should fix them but they don't mean anything bad.

[Menno]

OK so I tried the new Firmware posted by James yesterday. Everything works like a charme. It took a little PID tuning )not easy in windy and rainy conditions :-)) but she flies smooth as silk and yet crispy on the controls. I like it.

I am wondering if there is a scientific approach for tuning the AccelTau and the GyroTau filters. Is a bluetooth connection mandatory for this so the scopes can be saved to a logfile?

Here is the current setup for my quad:

controller STM32F3Discovery with FlyingF3_txpid.opfw

mtm distance is 450 mm

motors are Sunnysky X2212-13 980 KV

props are  Gemfan 10*4.5

ESC's are HK 20A flashed with SimonK firmware

battery is 3S2200 mAh

auw is 1065 gram

Inner loop PID settings in GCS are:

P 0,00184

I 0,00100

D 0,000127*

Outer loop:

P 2,200

I 1,5

GyroTau 0,015

AccelTau 0,025

* with the Derivative value at 0 the quad flies absolutely horrible, like a drunken bug. If I make a sudden steering corrections it wobbles like 4 or 5 times before it's stable again.

If weather permits it I will go to the park tommorow to make some flights. I will probably need to tune the I value further as the current values are from flying in my back yard.  

 

[Kenn Sebesta]

There are some scientific approaches, but they tend to be data driven. On a standardized platform you can make certain assumptions about how much vibration you have (which is what ultimately drives AccelTau and the GyroTau values to be higher). However, for experimental platforms (which in some sense is what everyone who builds their own quad has) it's hard to know how best to approach the problem.

What I hope we'll have sometime in the near future is the ability to test hardware against known good platforms. Maybe compare an AutoQuad-- the reference in stability-- with other hardware. That will help fine tune the range of good values. However, the empirically determined constants seem to give pretty good flight results. 

Glad you got it flying so well, and thanks a lot for posting your parameters. The AccelTau and the GyroTau values look pretty reasonable. Those will come in handy for when we finish the reference design and make a release.

[K DUB]

Here are two Android Apps that I use to measure vibrations

https://play.google.com/store/apps/details?id=com.maxcom.vibrometer&reviewId

https://play.google.com/store/apps/details?id=com.lul.vibration.monitoring&feature

This is one method I use to gain empirical data

[Menno]

Unfortunately using an android application will not show how AccelTau and GyroTau affects the sensor data.

I made some flights with the Flyingf3 firmware in the park today. Bear in mind that I have limited piloting skills. Maybe I am the best test subject for that matter. If I can fly it than everybody can :-).

First video starts with the derivative value at 0. At 35 seconds in the movie I mix it in at to a value of 0,000125. Wind is approximately 15 miles/h (4 Bft).

http://youtu.be/41bJbWIZaDQ

The second video is where the wind comes from the left side. What I really like in this movie is that I hardly have to use any throttle input to remain at altitude, even in ground effect.

http://youtu.be/47U5NzPVeNk

Remarks:

- In the old firmware I did not have to dial in the derivative value to get rid of the bounces after making steering corrections. This was a new phenomena to me.

- I really like to use the TxPID module to make adjustments as I don't have a bluetooth module yet. Can I make a feature request for adding AccelTau in the TxPID module? GyroTau is already in there. I would like to find out how low I can get the filters without loosing performance. 

[Lilvinz]

Menno, odds are that you are the first on earth who piloted flyingf3!
This looks very promising.

[cyr]

FWIW, my approach to AccelTau is stick it at 0.1 and forget about it. You probably will not gain anything from lowering it since it's not really in the control loop, and any higher is just plain silly :)

This is what the OP wizard does now, I think.

GyroTau is different, because it really is in the "critical path".

You will probably find that you can get rid of "ringing" after quick inputs either by lowering Kp or adding just the right amount of derivative.

[Menno]

Hi Cyr, standard value in the Flyingf3 firmware for AccelTau seems to be 0,02. If there are no negative side effects than maybe the standard value can be raised. Although making your airframe vibration free should always come first.

Vinz, it's to bad that I can't earn any awards here LOL. However If I am correct James had already tested the F3 board, so the award should go to him in that case.

[Menno]

So here is another boring video of me flying my Tricopter. I have loaded the FlyingF3 firmware on the board this morning without any problems. Wind outside is still a gusty 15 miles/h (4 Bft.). At the 1.15 minute mark in the video I do a hands off hover in Rate mode which hold reasonably well. After that I switch it to Atti mode and it drifts away (straight into the wind) after just a short moment. So it seems I have some tuning left to do in Atti.

http://youtu.be/joLHJ8n0E8M

[peabody124]

Just out of curiosity did you do the 6 point calibration before leveling it and did you find that intuitive/simple to perform?

[Menno]

I did not perform the 6 point calibration this time. I tried it before on my quad (has the board mounted upside down) but it gave strange results, maybe because I had 180 degree roll set before doing the setup?

What I find confusion is whether you need to hold your vehicle at an exact angel of 90 degrees to the left, right etc. How precise should this be done? Also should I notice improvements in stability because of this? Kind of like dancing around with the frame in Autoquad :-) ?

[Kenn Sebesta]

The roll rotation being set before 6-pt calibration shouldn't affect things, as the bias and scale calculations should be happening before the roll-pitch-yaw rotation.

You don't need to hold it perfectly at 90 degrees, close enough is good. What you do need to concentrate on is holding it very still. This is because we sample the data inside the GCS, instead of inside the FC, so that means that we are likely below the nyquist frequency for the subtle hand shakes due to your heart beating. 

In short, if you can prop the model up against something that's not perfectly 90 degrees, but so you're not touching it during the data gathering routine, you'll likely get better results then if you try for perfectly 90 degrees but are holding it.

[Menno]

That is where I went wrong. I kept the airframe upright with my hand while I was calibrating. I will try to the 6 point calibration again. Is there any way to check if the collected data is valid?

As this is a new feature maybe it's worth to open up a new topic for the 6 point calibration?

[Kenn Sebesta]

I'd like to explore some ways to validate the data automatically. The easiest way to do it is to look at your accelerometer readings while the board is at different rotations-- upside down, on its side, etc... Check that the accel reading for the correct axis is close to 9.805 when the other readings are 0. Above all, never more (on average) than 9.805.

We could start a discussion about the six-point. Ultimately, it's supposed to be something you do once, and then never again. Not once per model, but just once. We've not done an excellent job on communicating this, as it's a bit tricky to tell users that they don't need to redo this, except when we tell them to erase their boards. Which is something historically we told them to do every time they started with a new UAV.

[Menno]

[quote]The roll rotation being set before 6-pt calibration shouldn't affect things, as the bias and scale calculations should be happening before the roll-pitch-yaw rotation.[/quote]

I'm not sure if I am reading this correctly. The last time I tried this on my quad (with the board upside down) the readings where way off (like 90 degrees).

Since the 6 point calibration is not airframe dependent, can it be that when it asks me to tilt 90 degrees forward that I need to tilt the front side of the flight-controller 90 degrees forward and not the airframe?  as the bias and scale calculations are happening before the roll-pitch-yaw rotation?

The paper plane made me think that I could rotate my Quadcopter in the requested direction.

Now that I got this of my chest I can finally go to sleep :-)

[Menno]

Ok, so I did a six-point calibration on the Tricopter Flyingf3 board. I have this board mounted sideways and therefore I had 90 degrees of yaw setup in the INS module. It seems that the board rotation is (temporarily?) reset to zero once you start the six point calibration procedure. I rotated the board in all directions as if it was still installed on my tricopter (with 90 degrees of yaw).

To perform the calibration as accurate a I could I used clamps to fixate the board in position and a spirit level to have a near exact rotation.

After performing the calibration the board rotation gave an exact 90 degrees on the yaw again. So it seems that this calibration can be done while the board is rotated in the airframe. I am not sure but I think rotations of the board should be in multiples of 90 degree in each axis since otherwise the axis are not independent?

The artificial horizon follows the motion of the board as it should, and accel values are close to 10, so it seems that the calibration was a success. How do you guys get an absolute reading on the accelerator value? Even if I lay the board down the values fluctuate between 9.8 and 10.2. Is it normal for the reading to fluctuate 0.4 points while not in motion? Below is a screenshot with the board banked 90 degrees to the right.

[Menno]

Can one still perform the board leveling procedure after the six-point calibration?

[peabody124]

Yeah some degree of noise in the measurements is normal.  I'm curious what your accel bias/scale values are in the InertialSensorSettings object.  Personally I'm never that careful when doing it myself.

Once all is done you should be able to click leveling like normal.  The nice thing about how this is implemented is the scale/bias is now applied before the rotation so as Kenn said shouldn't have to be repeated.

I'll be interested to hear if you perceive any difference with this procedure.  I suspect for multirotors we can have a simple leveling button which does what we used to.  For fixed wing this is more important.

[Menno]

Zero and one? Attached is a screenshot shortly after I did a boardlevel. Connecting it to the GCS without doing a boardlevel leaves InitialGyroBias settings also at zero. I have never altered thes values before. Is it 'just' to trim out the multicopter while in hover or is there more to gain. In that case I will have some reading to do.

 

[peabody124]

Hmm... that makes me think the values weren't saved after your original calibration.  Could you retry the 6 point calibration and see if they change?  The initial gyro bias will change after leveling.

[Menno]

So I have done the six-point calibration again. This time I did not do it as precise as the previous time. Below is a screenshot made directly after the calibration succeeded.

Although the values in the UAVobject browser are not colored yellow or green I pushed the save button just to be sure. After that I gave the board a reset and all the values where gone again! Apparently the values where not saved to the non-volatile memory.

I have entered the values for the AccelBias and Accelscale manually after that and then it does save them to the non-volatile memory. So it appears to be a bug in the six-point wizard?

Are there any other values altered after the six-point calibration? I would like to enter them manually so that I can test whether a difference in stability is noticeable.

[peabody124]

That's quite odd.  It might be an error specific to the Flying-F3 build and I'll test it out tonight.  In the mean time here is an updated version

https://dl.dropbox.com/u/6645063/AboveGroundLabs-20121231-a8ee034d-install.exe

https://dl.dropbox.com/u/6645063/AboveGroundLabs-20121231-a8ee034d.dmg

https://dl.dropbox.com/u/6645063/abovegroundlabs_0.1.0-20121231-a8ee034d_i386.deb

https://dl.dropbox.com/u/6645063/abovegroundlabs_0.1.0-20121231-a8ee034d_amd64.deb

Fixed links

[Menno]

I am afraid that the new FlyingF3 file (fw_flyingf3-20121231-a8ee034d.opfw) does not boot once flashed to the board. When I flash the previous F3 file to the board it boots without a problem in the GCS.

From what I can see in a first glance in the new GCS you people have been busy! 

[peabody124]

Check here https://groups.google.com/d/msg/phoenixpilot/kf_BQ7g8qug/Bl78tWdqazIJ for some fixes for the flying F3

[AlPackin]

I just updated the FW on one of my quads.  It uses a Spektrum sat RX and I couldn't get it to bind.  Set the DSMxBind to 5, save to board.  Disconnect USB, power up board with battery and the RX led should come up blinking in the bind mode.  Tried a few times then went back to FW from 11-8 (first Phoenix I think) and I was able to bind and fly fine

[AlPackin]

oh yeah, that was a CC3D board

[Menno]

I am also not having any luck with the 20130210 build.

- there is no response on UART2 telemetry

- UART4 and UART5 still cause boot faults (and don't remeber there state after reboot)

Also there something wrong with the texts above the output update speed module (see picture).

All, I believe you also use Windows. Can you confirm these problems with the latest build? 

[Lilvinz]

Menno, i have fixed both problems but the code is still under review.
Keep an eye on this: https://github.com/TauLabs/TauLabs/pull/309
Or even better, step ahead, try it and report back on that pull request.

[AlPackin]

this version works with Spektrum sat

[peabody124]

Also the "?" are intentional - before the numbers were simply incorrect.  That's a place holder until we migrate that stuff into the board plugins.  For quads just set everything to 400.

[Menno]

Did some tests tonight on my Flyingf3 board running the release from February 12th.

UART outputs 1 to 5 only work one at the time. Using 2 UART outputs at once (e.g. Bluetooth on UART 1 and GPS on UART 2) result in a bootfault. The bootfault can only be restored by saving the outputs again with the UART values on disabled.

I am also having some trouble configuring my Crius V2 GPS receiver (Neo 6M). I could only save a maximum baudrate of 38400 to the EEProm and no UBX signal, just NMEA. This is probably just my lack of knowledge of the U center software (what a horrible program). Therefore i decided to try the GPS configuration file that 3DR uses for Arducopter as this forces it to use the UBX protocol.

After writing the 3DR configuration file to the GPS I connected the F3 board with the GPS to the GCS. I get a green GPS light on the System health indicator quite fast. The PFD and the GPS windows however do not update the values. I don't know whether this is because the GPS is not conifgured as it should be or whether this is a problem with the GCS?

[Menno]

BTW, have there been any changes since the February 12 build? The Jenkins artifact folder seems to automatically generate new builds every 48 hours. But how do we know whether it is a changed build?

I also wonder if I can test the Position Hold function on the F3. You can select it under the Flight mode switch settings but I don't see any adjustable parameters?

[Kenn Sebesta]

Jenkins generates new builds when "next" advances. So if you see something new it's because there's new code. Not that you have to feel you need to chase next, we're adding features quickly, but not so quickly you should be upgrading every day.

I'm not aware of anyone doing position hold yet on F3. I don't think the process is documented.

[Kenn Sebesta]

That's strange, your GPS shouldn't be green unless there's a fix. However, looking at the rest of the screenshot I see that there might be a little more to this than at first glance. It's possible that the GPSPosition UAVO is not configured to transmit. You can see in the metadata what its update mode and rate are.

Can you take a look at the PositionActual and VelocityActual UAVOs and tell us if you see them updating? The GPS UAVO is only used internally for estimating position and velocity, so those are the two you want to focus on.

[Menno]

I wil have a look at those fields when I get home tonight. Strange thing is that the satellite updates where oke when the Gps was still on nmea protocol. Although gcs should never give a green gps light in the system health indicator when apparently it is not, I believe this is caused by a faulty gps configuration.

Perhaps someone can share the correct configuration file for this Gps with me?

[Kenn Sebesta]

Here's the configuration file for u-blox. This will make the GPS output UBX only, so NMEA will no longer work.

I don't believe that you have a faulty GPS configuration. The green light comes from the alarm module, which means that the GPS has a full lock. This is either a firmware bug, a UAVO misalignment, or a GPS lock. I strongly doubt it is a firmware bug that is sending an OK signal if there is no lock. Are you getting warnings when you plug in your board?

For reference, I've included a screenshot taken with Quanton. In this case the GPSPosition UAVO is being updated, which is normal for the default settings. I need to test with FlyingF3 next.

[Kenn Sebesta]

Using next (commit 5ab32a3), I have individually tested each UART and can confirm that the GPS works on all 5 on the FlyingF3. So we should dig some more into your problem to understand why you're not getting the same results I am (see screenshot).

[Menno]

While you're working on the F3. Can you try configuring more than one UART ports at once?

Using one UART port of choose works fine. Assigning more than one port at once results in a bootfault once rebooted. eg. telemetry on UART1 and GPS on UART2.

[Kenn Sebesta]

I cannot reproduce this bug. I am able to assign all UART ports at once, without experiencing a bootfault after rebooting.

[Menno]

I guess that it is good news that it seems to be a local problem.

To do's for tonight:

1. check the PositionActual and VelocityActual UAVOs values with my current configuration.

2. Do a clean install of the latest build and check whether I can use multiple UART ports at once

3. check if the GPS information is updated correctly, else install the new Ublox configuration file and retry.

Thanks for the help this far!

[Menno]

I have installed the latest build on my F3 board (jenkins-taulabs-next-win32-418:5ab32a3b 20130227). Asigning more than one UART connections does not resolve in a boot fault anymore. So I guess that that problem is solved.

[Menno]

This GPS thing is driving me crazy. I have updated the GCS and the F3 board to the latest version (jenkins-taulabs-next-win32-418:5ab32a3b 20130227). I also have written the configuration file for the GPS that you have send me. Writing this or the 3DR-Ublox file does not go without warnings. Some warnings are about the version, other warnings are about timeouts. After writing the configuration file the Baudrate is set to 57600 and update rate to 10 Hz (I think 5 is the maximum supported?). After rebooting the GPS the baudrate is reset to 38400. No matter what I try. It won't store any baudrate settings higher than 38400.

GCS gives the below image.

- VelocityActual is updated

- PositionActual remains on 0.

- SNR and PRN data is updated

I think the system health status looks at the SNR data? It moves form red to yellow and green depending on the number of satellites visible from the SNR bars.

When I connect my old GPS to the board on NMEA protocol the satellite updates are fine. The number of GPS fixes are visible in the PFD display.

[Menno]

Also it would be great if we could use the yellow led on the F3 board as an GPS status indicator. At the moment there no way of checking how much satellites are locked without telemetry. Something like:

- flashing yellow led -> no lock

- slowly flashing yellow led -> locked on to less than 6 satellites

- yellow light constant on -> locked to 7 or more satellites

Would this be easy to implement or would this be too board specific?

 

[Kenn Sebesta]

Some warnings are normal, as the moment you change the baud rate the rest of the communications are lost. So you always have to flash the settings file twice.

That looks like some progress. Have you set HomeLocation? "if ( xQueueReceive(gpsQueue, &ev, 0) == pdTRUE && homeLocation.Set == HOMELOCATION_SET_TRUE ) {"

[Kenn Sebesta]

That's probably feasible, but we wind up having an indicator on the FlyingF3 that we don't have on other boards.

Does the GPS not have an LED that tells you it has lock? I know mine do, but I suppose that's dependent on the manufacturer.

[Menno]

I have the Crius CN-06 V2 from Goodluckbuy; http://www.goodluckbuy.com/crius-cn-06-gps-receiver-v2-0-module.html

As far as I can tell it only has a solid green light on the bottom side of the board. It flickers a little bit bit when data is transmitted but I can't find any logic in it.

[Menno]

shoot. I forgot to set Homelocation after loading the new firmware yesterday. Can this be a cause for not displaying the number of satellites in the PFD? I find it odd that satellites are displayed with NMEA protocol.

[Kenn Sebesta]

It might be that the field that the PFD is using for the number of satellites isn't being populated when using UBX formatted data. I'd have to look into it. Can you file an issue, and perhaps include some screenshots?

[Menno]

Flying with the 20130227 version of the F3 firmware was no succes for me.

First I had a problem with the board endlessly rebooting after enabling TxPID module, GPS and Telemetry. (logfile and UAV export)

- I can't get telemetry running on UART1. On UART2 it runs just fine.

- With telemetry and GPS (module) active the board reboots(?) in the middle of flight. This was while flying in rate mode. As if there is a stack overflow after a certain amount of time and power is cut. It happened 3 times in a row. Unfortunately I don't have a logfile from this flight because the Telemetry was not running.

- I had to lower the PID setting with the same airframe. (did something change?)

I have set the firmware back to 20130212 for now. Enough propellors broken for one day.

[Menno]

Darn I crashed my quadcopter. I was about half a minute in flight when suddenly throttle just dropped like it did earlier today on the newer firmware. I had my keycam on board (youtube video) and telemetry was also running (logfile) although I doubt that I was in Bluetooth range.

I am realizing now that not to long ago I enabled failsafe on my PCM transmitter (Futaba 9C). Until then it was on hold instead of failsafe and I wanted to make certain that it would come down instead of fly away if I ever got out of range. Strange thing is that I was only 60 feet away when this happened.

What I would like to know is whether this is a problem with my Tx/Rx or if this is a problem with the firmware. Unfortunately the logfile created by the android application still produces errors when I try to load it in the GCS so there is no way for me to see it.

Can anybody assist me with this?

[Lilvinz]

I will investigate this one right now.

[Lilvinz]

you said you used 20130227 but there are two builds from that date. please clarify.

[Lilvinz]

Can you give more details on that one like .uav file and used build as well?

[Lilvinz]

Regarding USART1 are you sure you have the pins right?
After fixing the usart problems i have tested telemetry on every single uart.

USART1_RXI (PA9)
USART1_TXO (PC5)

[Menno]

uav file is here. It's from build [taulabs_next_20130212_165250_885ca212c2_win32]

Not knowing whether this is a firmware issue or a Tx lock out is my biggest concern at the moment.

[Menno]

This was build [taulabs_next_20130227_153625_5ab32a3be9_win32]

With this build I had telemetry on UART1 and GPS on UART2. When I activated the TxPID module after that I ended up in an 'endless bootloop'. Here is the debug file.

[Menno]

I will check the UART1 telemetry function tomorrow morning.

[peabody124]

Can you post your log file?  I don't tend to replay in GCS but can probably analyze it for you in matlab.

[Menno]

It's a few posts up: https://groups.google.com/d/msg/phoenixpilot/mfwikNUZ5-I/NMHr_O2Z-IIJ

Google refuses to attach these type of files to my messages so I put them on my site and link to them. I hope you can get anything from it because I don't know if I was in Bluetooth range during the crash.

[Menno]

Bluetooth works on all of the U(S)ART ports.

GPS works on all of the U(S)ART ports.

Connecting the 2 devices simultaneously results in a bootfault and all of the UART ports are set to disabled.

Based on Qt 4.8.1 (32 bit)
Built on Feb 12 2013 at 18:30:54
From revision jenkins-taulabs-next-win32-397:885ca212 20130212 16:52

UAVO hash cee76440f856e6075ef7116490ed1171f4c613 

[Menno]

I am updating the firmware to [jenkins-taulabs-next-win32-418:5ab32a3b 20130227 15:36] to see if I still get bootfaults when connection more than one UART. I updated the bootloader first and then I loaded the Firmware to the board.

While setting up the system configuration the board lost connection twice. I have not even started the Tx setupwizard nor have I made changes to UART ports. Attached is the debug file.

[Menno]

Activating both GPS and telemetry on the  [jenkins-taulabs-next-win32-418:5ab32a3b 20130227 15:36] build causes an near endless boot loop on my board; movie

[Reddog]

Is there a current build that can be used on the CC3D that works for Fixed Wing? Are there instructions for getting a corresponding GCS setup? I heard the other day that RTH works on the CC3D and I was wondering if that was available for Fixed Wing yet? I would love to start working on testing this stuff. If so, I will create a separate Topic that discusses this and has some instructions for non coders.

[Lilvinz]

Confirmed. I am searching for the root cause which seems to be deeply buried in the system firmware.

[Kenn Sebesta]

No, there is no current build that supports RTH on CC3D. The code I wrote in kenz/cc3d_nav should still work, but that's going back to October. Unfortunately the structural problems that prevent autonomous flight on CC3D still persist and it currently looks unlikely that this situation will change.

[Reddog]

Is there currently a firmware build and GCS that is stable enough to fly with on CC3D? I had a look at getting a Discovery F3 and they cost $40 in Australia including shipping. I wasn't particularly keen to get one for that price (and size) when the Quanton can be had for $100.

[AlPackin]

If you mean flying a mutirotor, all of my CC copters are flying TL firmware. I don't think anything is really changing on that platform but I could be wrong.

[Reddog]

No I mean Fixed Wing, so many multirotor flyers, figured I should be working on the fixed wing.

[AlPackin]

In so far as the devs can't get any OP hardware anymore I don't think you will see any development in that direction.

[Reddog]

Thats OK, I don't mind. I would like to get started using TL software on the CC3D board, even if its just standard firmware with no hope of future feature development.

[Kenn Sebesta]

The problem that CC3D will have with flying fixed wing craft is that with the current filter its attitude estimation will get confused after long turns in the same direction. If you're just flying around  in rate mode, or you're flying in attitude mode but are not making long turns (>3s) then you should only experience this problem to a negligible extent. In fact, it's possible you won't even notice it.

This problem was solved in kenz/cc3d_nav through the introduction of a more advanced filter.

P.S. I still have two CC3D, so work could conceivably be done in that direction.

[msev]

Hope at the same time you'll work also on flyingf3, maybe that magnetometer which it has could help also? 

[Reddog]

I am surprised CC has such a problem with the firmware, I was never aware of this.

I guess the question is how much work will be required to get the CC3D/CC working as a stabilisation platform? I don't see any issue with getting the CC3D/CC to a point where there is a stable firmware for stabilisation, GPS , telemetry and leave RTH for someone else to work on. Freeze the firmware and leave it at that.

There are plenty of CC boards out there and the hardware is stupidly cheap to make. I can see normal flyers using the CC for a long time or others using the CC software on an integrated stabilization/receiver. Myself I see CC as a great FPV platform if it had RTH.

Development can then continue with other more advanced platforms.

I have no idea about the time required to get CC to that point so I cannot say if the work is worth it or not.

[Menno]

Off topic. Went flying with my tricopter today running a Multiwii board and 35 mhz ppm rx (my quadcopter has a 35 mhz pcm rx). The rx on my tricopter has a hold function and just as I gave it a burst of throttle it became unresponsive for about 2 seconds. Luckily I got control back after that.

On my quadcopter failsafe is set to 0% throttle. Now I have a strong feeling that the sudden loss of throttle that crashed my quadcopter last weekend is due to a failsafe situation caused by a failing Futaba 9C transmitter and not a reset of the F3 board.

I know that this is not Taulabs related but does anybody know a way to test the signal transmitted by my transmitter. Can the ppmsum be measured in the gcs?

I love my 9c transmitter but I don't know if its worth sending it to a Futaba service center. I bought this tx in 2005.

[Menno]

I'll tap in to the RSSI pin of my Futaba R149DP Rx tonight and attach it to my multimeter. If I am correct than any lock outs should be visible on the multimeter where the voltage would drop from 2,2 to 0,5 volt. Would be great though if the RSSI signal could be read on the scopes of the GCS.

[Menno]

Nope, no matter what I try the lockouts can't be replicated. I had the quadcopter running without props and a multimeter attached to the RSSI line of the receiver. I let my son walk through the park with my transmitter while constantly moving the sticks. Al this time the voltage on the multimeter did not drop below 1,5 volt. Failsafe voltage is below 1 volt. 

[Menno]

I have notices that in the latest build that I pulled from Jenkins that the scopes are not running in the GCS?

I also tried connecting the board to an older version of the GCS. In the older version I do get a timeline running below the graphics but still no scope lines.

PFD, system health and everything else seems to run fine.