Freedom INS testing

[peabody124]

Here's a video of using android GCS for getting logged data from Freedom:

https://vimeo.com/59261900

also the overo was collecting high speed log data for analyzing the INS performance.  Both things worked.  The tablet was great for checking on the status and tweaking a few settings.  The overo logs worked flawless and I have all the updates I could want :)

Here are some cool examples:

1) So here the top plot shows the throttle and acceleration in the forward direction.  You can see there is pretty little lag between the two.  The bottom plot shows the INS response and GPSVEL response.  You can see the INS respond with less lag than the GPS which is good (and it should) but in the end you see it seems to take a while to come back down.  I suspect this is from yaw inaccuracy.

2) So here the little arrows show the INS estimate of velocity and the position of the arrow is the current estimate of position.  You can see there the arrows seem to run in the wrong direction and then jump back (when a GPS position update occurs) which is consistent with that yaw problem described previously.  For longer runs in the same directions eventually the GPSVEL pulls the INS into the correct estimate.

3) And here to confirm that I plot the yaw estimate versus the raw magnetometer.  Clearly they are barely related.  So now the first priority is getting the INS tuned (and possibly modified) to make this more robust.

[peabody124]

Cool.  And the overo doesn't distort the magnetic responses which was one of my fears:

[Kenn Sebesta]

That's a beautiful graph. Do you get the same behavior out of the accelerometers?

[peabody124]

Yeah but I wasn't trying not to apply real acceleration so it's a lot noisier:

[peabody124]

Ok more fun.  So this is testing position hold on a quad.  Some of the holds worked well and some didn't.  Interestingly it's quite easy to tell which is which.

Here are two position holds that were reasonable (still 2 m so not good enough):

And here is one where it didn't:

What is striking in the one where it didn't is the INS velocity does _not_ point in the direction of the change in position.  Basically it already thinks it's moving in the desired velocity so doesn't apply much attitude to fix it.  

When I overlay the GPS velocity:

it appears the GPS velocity is fairly accurate so it needs to be trusted more in the EKF.  Also I'd like to figure out why the INS ends up pointing the wrong way - whether the heading estimation is failing so acceleration is getting integrated in the wrong direction or if it is just noise.

[peabody124]

Ok, looks like the heading was tracking the mag pretty reliably.

[peabody124]

Replayed the sensor data through the EKF with lots of different parameters and found something that works quite well.  This will be fun for testing:

[peabody124]

Ok new settings work pretty well:

It looks pretty crowded cause it stayed within 2 meters.  I burned through two batteries with these settings without any problems which is nice.  You can see the INS and GPSVEL arrows consistently point in the direction of the path.

There's also a new mode that lets the attitude come from the complimentary filter which is almost working which I think might make things even better for quads.  I'll repeat tomorrow and get some video.

[mnuapel]

Wow, this already looks very very close to target.

[Y Jung]

Hello

I am a new comer who have a strong interest in this area.

Congratulations your achievement, and I have one question ;

If the INS positioning accuracy is close to GPS at around 2 meters, may I use this result in indoor positioning applications,

such as autopilot in building environment where GPS is no longer useful.

Hope to receive your comments.

[Kenn Sebesta]

Y Jung--

What would you use for absolute positioning if you didn't have GPS? I have written a module to take in data from a motion capture system and stream that to the vehicle, but most people don't have $20,000 to spend on this kind of lab. It would be nice to have an alternative between the two.

[Y Jung]

Sometimes we are suffering unknown interference for GPS signal reception,

That's why I am asking this question. 

and when we think about the firefighter's working environment, most of them are working in indoor with maximum risks.

I think we could protect their life with this achievement.

[peabody124]

So for the sake of full disclosure, it's not always that good.  Here are two flights with ~20 mph gusty winds.  I've also tweaked some settings and you can see the EKF and GPS velocity don't coincide so well.  I think I'll step that back a bit

Notice when it swings really far to the north east that it seems like the EKF gets relatively disoriented for a bit.  Because it already thinks it's mostly heading in the direction desired that means it won't try and tilt the quad that way.

In this one I think the EKF is actually doing quite a good job of staying ahead of the GPS so it's actually probably doing the right thing.  Either way, you can see it's moving quite a few meters.  The precession needs more looking into - it _could_ be because of heading error but I'm not entirely convinced.  I'll try and add some code to see which way the quad seems to be tilting and figure out what is consistent. It might be that we want separate velocity PID settings for the component in the direction of the target and the normal.

[peabody124]

Here I overlaid the "drive" arrows which is the direction it is tilted.  As expected you can see those basically would go from the current to the desired velocity.  It's definitely my impression that it isn't trying hard enough to suppress the momentum in the normal direction.  However, within the space I've searched simply increasing the current PID settings doesn't seem to help much.  

I'm thinking maybe more velocity Kd for damping?  Second set of PIDs?  Kenz ... suggestions?

[Y Jung]

Can I do the INS performance testing like you,

 if I build the SW and make Freedom board HW from github repository.

because there are so many boards, and that makes me confusing. 

and let me have one more question,

 what is the road map and goal in this research in terms of feature and performance.

[RC Flyer]

There are designs using dead reckoning technique especially for firefighters where GPS reception is limited.
http://www.youtube.com/watch?v=YMcLY2R6qBg
I am not sure if this technique can be used for flying devices. It IS actually used in commercial jet liners but the sensors they use are higher accuracy.
Y Jung, I also have a couple questions for you regarding another topic. Would you please to PM me?

[Y Jung]

What is the main purpose of OVERO in the Freedom boards?

[peabody124]

It's fairly open ended.  Right now I'm using it for collecting complete logs of everything that happened on the FC which is really really useful for working up and testing new algorithms offline.  In future I'd like to use the extra processing power for some adaptive control algorithms and the caspa camera for some image processing applications. 

[Kenn Sebesta]

What James said.

In addition, you can do lots of fun things with other non-flight critical ideas. So you could do complex sensing, mesh networks, SLAM, etc... Basically, you can have the CPU horsepower without sacrificing the stability.

[Y Jung]

I agree to the potential possibility of OVERO, but one thing to bear in mind is tat TI decide to close OMAP. This is what I heard recently.

[Y Jung]

James,

When do you planning to upload the codes for Freedom Board with INS updated.

I would love to fab for people who are interested especially in INS.

 

[peabody124]

The code for Feedom is already in the repository.  I have about a month worth of changes to the INS to check in, but I'm not done with them and the code still needs some cleanup before it's push ready.

[Y Jung]

That means there is no modification on Freedom board in HW, but need clean up process is required for the codes, Then may I use it as a basic framework platform for the development of indoor/outdoor positioning technology. If yes, I will start factory fab process immediately.

When do you expect to finish the clean-ups.   

The final application could be a "Fully Autonomous Flying copters for Indoor/Outdoor environment", similar to the research activity from MIT, Penn University, UC Berkeley, and so many others.  

[Technium]

I don't mean to sound pushy in the slightest, but can I ask the state of this code? I'd love to have a play with it with the eventual aim of improving position stability when no GPS is present at all.

[peabody124]

It's coming along well.  I'm flying it pretty much every day, and have made a fair number of changes to the INS based on analysis of the logged data.  The majority of the code is checked into github except for some testing stuff.

I still haven't spent the time to try and salvage another serial port which is what has blocked me making more.  The fact I ripped the GPS header off in a rather spectacular crash yesterday might get me moving again :)

[Technium]

Excellent news (well, apart from the GPS header).

I've clearly failed to find your code in that case - can you give me a pointer? I checked your github branches, etc and couldn't see it.

[peabody124]

fight/targets/Freedom

[Y Jung]

Think, you may already aware the importance of auto-navigation in the GPS denied situation, 

This can be a differentiation factor comparing to other projects.