quanton flight control

Darrell February 22, 2013 at 1:15pm

I am getting warning messages about missing synthetic files. I am running ground.pro in qt_creater. I have read the notes in ground.pro about rerunning qmake for abovegroundlabs.pro. I could not find abovegroundlabs.pro on which to run qmake. I have searched previous dialogue and did not find this topic. I may be asking a question with an obvious answer, but I am not a coder.

lilvinz February 21, 2013 at 2:11pm

I think FOSS is JTAG only and does not support SWD but i am not sure about that. The cheapest SWD adapters i know are the STM32 Discovery boards from ST. They all embed an ST Link SWD adapter.

I will double check on the old OP based code if it is still fine to use with release version of quanton board (there may have been minor pin reassignments which i didnt port back yet). I will let you know when this has been checked.

As for Kenn's comment regarding the cases, he is just referring to the fact that Tau Labs is not a hardware provider or vendor. Tau Labs just maintains software which runs on several independent manufacturer's hardware like OpenPilot, ST Microelectronis and Quantec Networks. I could pretty well imagine making a nice case for quanton especially because we have several 5 axis CNC mills near to our SMD pick and place line :)

The newest toy is this one (which is very fast because of linear drives): http://vimeo.com/59993824

lilvinz February 21, 2013 at 12:56pm

You are right, there used to be binaries on my github page but github removed the downloads sections.

https://github.com/blog/1302-goodbye-uploads

Besides that, it wont be as easy as flashing another .opfw file onto the board.

E.g. you would have to flash the bootloader for the board id to "fake" cc3d again. As we currently do not have a bootloader updater image this requires SWD access to the board so you would need a debug adapter as well.

To avoid this, the "old" OP port needs some intense handcrafting which i still try to find some time for.

I will do it but don't nail me down on a time frame.

James Cotton February 21, 2013 at 8:09am

Yep, that alarm checks for a whole slew of errors that cause you to have a really bad day (including that autotune fly away) such as the ability to enable position hold if you don't have running any modules to control your position.

That's not to say we check for everything so I'm sure if you get creative you can cause a problem :).

Kenn Sebesta February 20, 2013 at 1:26am

That system config error is because you're trying to arm the model while it is in an inherently unsafe configuration. You might have left one flight mode in manual, for instance.

In order to interpret this error more informatively, check the UAVO browser-->SystemAlarms. I recently implemented rich errors, which give you specific feedback on why an alarm is firing. You should be able to see which exact system configuration error is causing the complaint. If you have trouble interpreting the errors code, let us know. I strive to make my error messages as intuitive as possible, so if I've missed the mark I will try to make the error clearer.

As for documentation, it's about exactly the same as OP, with the exception of a 6-pt calibration. Which you don't have to do unless you want to. Feel free help us port our work (because let's face it, we authored much of the wiki) to our servers.

lilvinz February 20, 2013 at 12:54am

Codes lives in here: https://github.com/lilvinz/OpenPilot (https://github.com/lilvinz/OpenPilot/tree/discovery/flight/Quanton)

What flight modes do you have configured right now? E.g. if you have AutoTune configured as a flight mode but the autotune module is not running, this error will raise and prevent bad things. You can enable modules using the UAVO browser "Settings->ModuleSettings->State".

lilvinz/OpenPilot

Fork from git://git.openpilot.org/OpenPilot.git to track Vinz's modifications (moved over to http://github.com/Taulabs) - lilvinz/OpenPilot

lilvinz February 20, 2013 at 12:45am

The bad system config means that your configuration permits something that could fail in flight.

The most time i get this is when there are flight modes configured but the according modules are not active.

As for the OpenPilot port, the story is like this:

When i started developing on OpenPilot firmware there was no Tau Labs. I cloned the OP repository into my github account https://githum.com/lilvinz/OpenPilot. This is where all my initial work like getting the DiscoveryF4 as well as the DiscoveryF3 board flying took place. When i started quanton development i first added support for it to that repository. I had some 2 or 3 prototyping cycles and when the final hardware was ready (some time in december) i ported over and continued all my work to Tau Labs repository. I did that because my OP work was based on the OP master branch which had (and probably still has - i haven't checked lately) non working code for boards which uses any sensors except MPU6000 as well as because there is no proper support for different hardware within GCS as well as the flight code itself. All my OP based work "faked" to be CC3Ds in order be work at all. Now this is a serious draw back because that means not being able to use the mag and the baro at all.

I think its my fault that you assumed that port to be active because i posted Videos about Quanton and OpenPilot from this early development phase. When others have asked me about that i have promised to support OpenPilot code base as soon as there is some proper code in there for handling of those sensors. e.g. at least when those revo boards are out and being test flown or something.

Does that sound sane for you?

James Cotton February 19, 2013 at 6:33pm

/me Hesitates strongly to feed the troll, but that seems reasonable.

I don't consider it a closed development. You may. Both prototypes had the schematics posted. All the code is published (and most of it is used on Quanton). However, there is no upside of getting people to build duplicates of something that might change. It was nice with V2 cause I trashed support for V1 which kept the code cleaner. I wouldn't have that Freedom (har har) if people were making it and complaining about me pulling support. Frankly, I'll develop boards for my hobby as it pleases me. See the TL forums for more discussion of whether this revision is final (still haven't decided but it flies really well).

The problem with autotuning being selectable when not enabled was fixed months ago, which was the cause of the fly aways (and was easy to reproduce the described behavior). Still about 15% of the time (for tricopters and mini-quads mostly) the settings are too high which can be easily checked by looking at the settings before flying. I hope some of the model based approaches I'm working on now will improve the reliability and accuracy. In addition the code that was added applies a slew of checks before take off to cover common misconfigurations (but not all). But in short most of us are using autotune on our new quads (Kenn had 12 people at his hackerspace set up FlyingF3's and IIRC a lot of them used it) and we've had no bad reports worse than 'the tuning was way too aggressive after landing'.

I have a solid theory as to the PipX flyaway but since the telemetry was flaky it wasn't enough data to be conclusive. I believe I addressed the problem back then but it was months ago. Since the fork we've merged in ~200k LOC so it's really hard for me to comment what you should expect on the original code. Judging from the fact there is no activity in the original code I would imagine the problem is still there. It was greatly exacerbated by being a V1 RevoMini though which had worse telemetry SNR. The latest Freedom really has great RF performanceand I just went to analyze the logs for how well it is doing but damnit, that statistic is produced on the ground side :(.

However, I will HIGHLY caution you that I did manage to produce a situation with the recent code after power cycling the FC that my OPLink would not reconnect to the board. Both boards were working and heartbeating. Obviously if this happened in flight it would be disastrous. I had to power cycle the modem :(. On the flip side I have about 10 hours of logging telemetry during outdoor flights without issue ... so hopefully I dun goofed. For now I don't dare fly via OPLink for control cause I want to focus on other things.

We've also spend the last few weeks doing a large amount of data analysis and code refinement on the EKF to try and get the performance and reliability up (with some progress as my not-great-but-not-flyaway results in 20mph winds show). Right now there are a lot of knobs to turn and one of my goals of the data analysis with Freedom is to try and minimize the ones users need to turn (or ideally learn them automatically).

However, there are still NUMEROUS unsecured paths through the navigation code which is why I wouldn't recommend it for anyone at this point who isn't a dev familiar with the code. When I fly autonomously I have a series of hacky patches I merge in to ensure I can always bring it out of the sky. We have a thread at TL right now about a new pilot control structure that I hope will be more robust.

Regarding the rover, it's actually surprisingly hard on the EKF compared to being in the air. The mag tends to (for me) get hammered a lot worse, even on my small aggressor. See some tests here. I'm waiting for a replacement on the steering linkage for my car.

TauLabs/TauLabs

Contribute to TauLabs/TauLabs development by creating an account on GitHub.

James Cotton February 19, 2013 at 5:32pm

Yep, you could compare Freedom to Vaporware. Some differences are that freedom exists, and is producing amazing data that is helping refine position hold and develop some new cool attitude controllers that should also help essentially autotune the whole system for navigation (and benefit Quanton). Some similarities with vaporware are that there are only two in the world and the design isn't finalized or published yet.

You could also compare Revo to vaporware in that it was preordered with an 8 week lead time 4 months ago and it doesn't look they are out yet or even really have any updates. Plus, despite being hyped with lots of cool features I don't think anyone other than Sambas and myself have done anything autonomous with it. Nor has there been any public posts to indicate the design is either finalized or published. However, also differently than vaporware it is in the hands of some people who are making it control a car (admittedly with our code and not that I can knock it cause I was doing the same thing with Freedom to test the INS).

Anyway speaking of autotuning, I'm not sure that Lilvinz posted this video here. Autotuning is a pretty cool feature in Tau Labs

https://vimeo.com/58536515

that works a lot of the time to get the initial settings in a really good place.

Kenn Sebesta February 19, 2013 at 4:52pm

Not sure why people would think of an alternative manufacture CC3D, or that we (Tau Labs) would design cases. This board is not produced by Tau Labs, it's produced by Quanton Gmbh. It's weird to want to force an independent manufacturer into a specific mold. Really, anyone can produce boards that target our software, that's the beauty of open source.

The Quanton board targets Tau Labs software, so I can't imagine out-of-the-box results would be very good using other software suites, but I'm sure lilvinz wouldn't want to stop you from experimenting.

Blogs

quanton flight control

Comments