FreeIMU 4.0 and MultiWii - Is your copter trusted enough to fly above your car in a confined space?

As a huge follower of Fabio and his excellent FreeIMU I thought it time to post an update. I am looking forward to playing with the final release. For those who don't already know Fabio, he is a pioneer and well worth following.

 

Extract from the blog...

First flights of FreeIMU v0.4

The testing of FreeIMU v0.4 is proceeding nicely.. finally my friends Tilman and Warthox received their boards and as soon as they could they mounted them on their quadcopters for some flying tests. They used the brand new MultiWii software which me, timecop and Alexinparis have produced... the result?

Judge it by yourself..

p.s.: huge thanks to Warthox and Tilman for their time in testing the boards and making the videos!

 

Read more of Fabios blog here

Views: 4113

Tags: FreeIMU, MultiWii

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 8:10am

@r_l, I think more effort could have been put into making the tuning easier and at the same time reducing the need for so much documentation.

As far as diy is concerned most people are using the groundstation to upload/configure and also using pre-made and pre-soldered boards, some buying entire pre-made crafts. So it might be said that the diy aspect was lost a while back :)

In any event I don't think we need to be messing with pids, either the thing flys once built or it doesn't. Also true to say that if you alter pids and then build any changes into the craft then pids would have to be set again. Very boring! Personally, I would like to see more intelligence in this area and until then less in others.

I know that you didn't know any of this 6 months and have been impressed by your advancement however you have commited a lot of time which many diy users do not have.

Yes, I am also looking forward to the UDB solution. It was the first and easiest diy solution for planes and as has been rightly said, Bill is the man for the physics.

Comment by John Moore on May 18, 2012 at 8:13am

@Fab

 

I think a comparison chart is a great idea.


Developer
Comment by R_Lefebvre on May 18, 2012 at 8:32am

Yes, I have put a lot of time in, and do not expect everyone to be able to do the same.  But when I see questions like "My quad is completely unstable, what does Stab_P do?"  I just have little sympathy.

I would also like this to be simpler, but I don't think we'll ever have Plug and Play.  Not even the blackbox units do that.

At the end of the day, this whole thing is pretty much being developed by volunteers, and they work on what they're interested in.  I try to work on UI issues, or high level features, because it's all I'm capable of at this point.  The experts are working at a much deeper level, and they are needed there.  What we need are some new devs, experienced coders, to work on the high level stuff.


Developer
Comment by R_Lefebvre on May 18, 2012 at 8:33am

And unforunately... the "mythical man-month" problem very much applies here.  The code is quite large, and can be hard to figure out.  And when a new dev jumps on board, it can take a lot of time to get up to speed.

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 8:37am

@r_l one thing to bear in mind is that most new users ask stupid questions at first. I certainly did and I know you did :) I think UDB will come up with some solutions and no doubt they will be adopted into apm as they were in the first ap

@John, any ideas on where we might put a chart that everyone can append?

Comment by Ellison Chan on May 18, 2012 at 8:45am

Interesting discussion.  Well, now that I have experience Naza, and AC.  Here's my 2 cents on it.  The only difference between Naza and AMP1/APM2 is that the Naza has no GPS.  So the APMs compare more closely to Naza than the Wookong.  

May experience with the Naza, has not been pleasant, so far.  I've been working to get a stable hover for about a month, and just achieved it yesterday.  Since I'm using non-DJI motors and esc, it seemed that what was needed was to re-calibrate my esc.  I didn't calibrate them in the first place, due to the fact that in Manual mode, I found I was able to fly it relatively well.  This lead me to assume that the ESCs were sufficiently calibrated.  The problem, as Jason informed me, was that the throttle on these Nazas use something call "vario".  So basically from a coder point of view they don't pass throttle control, in a one-to-one manner directly to the motors.  The throttle control is quantized according to certain pre-defined settings, like 50% throttle, and 75% throttle, etc.  Since my ESC calibration was off this confused the Naza.

I will post a blog reviewing the Naza in some more detail, when I get more flight time.  But, I'm starting to understand the apparent feeling of stability that some newbies get from the Naza, and possibly the Wookong too.

Basically, you don't have direct control over throttle, and if things are calibrated correctly, you don't need to do much to get it off the ground.  This is not necessarily a good feeling for people, like me, who are used to the feel of the direct mapping of sticks to motors.

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 9:04am

Interesting points Ellison. I don't mind about direct mapping so there is a clear difference between our expectations. This sort of thing is well worth documenting and might remove fustrations for many. I am sure these things have been dicussed before in the bottomless pit of blogs and posts :) 

It seems a central chart would benefit so many people.

Comment by Ellison Chan on May 18, 2012 at 9:17am

Jason, the difference with Alt hold is that the drone will lock the altitude at the point the mode with switched.  When you leave alt hold, your throttle is read, and the drone adjusts accordingly.  The Naza only sets the throttle and attitude a pre-defined values.  This explains that video, when the guy is flying indoors in a corridor, and is able to just pitch it forward, and fly it to the end of the hallway, while the quad keeps perfect altitude.  You have no direct control over altitude for the Naza!


Developer
Comment by John Arne Birkeland on May 18, 2012 at 9:25am

@Lefebvre, I think the reason stability suffers is mostly related to sensor latency and timing. Even if the navigation only uses 1% total, that is 1% or 16mhz/sec total so for a sensor that can be a long time. And then you have all the other parts taking 1%, 3%, 5% etc each staked on top of that. And since the atmega is very simple monolithic system everything affects the whole. On "proper" hardware that 1% suddenly instead is 0.16% of 100mhz or 0.04% of 400mhz and so on. And on top of that you have grown up features like DMA, programmable interrupt priority and a lot of other nice features that makes it possible to ensure low latency execution and processing of critical data.


Developer
Comment by John Arne Birkeland on May 18, 2012 at 9:29am

@Fab, no idea :) Send a PM to Chris and ask I guess?

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service