“The problem is that we don’t understand the problem.” - Paul MacCready

[crashmatt]

Paul MacCready is one of the greatest mechanical engineers in aviation history.  His groundbreaking achievements, including the Gossamer Albatross and Gossamer Condor human powered aircraft,  were associated with solving the right problem.  Read more here:

Having read this recently, I began to wonder about what my autopilot problems really are.  I know roughly what I want to do but not what the obstacles are to get there.

Pete recently asked me when I was going to start the flying season.  My answer was "when I get around to rebuilding my aircraft".  What I actually mean by rebuilding is re-wiring.  The wiring harness is a nightmare. The aircraft is full of copper and has very little capacity for modification.  Installing the autopilot normally takes 2 hours.  If I could do something to remove that problem, I would be much happier about doing work on the aircraft.

That is my problem but not necessarily yours.  It would be very interesting to know what problems the group is facing.  This is not the same as a features wishlist. If you say "I want onboard flash", you are not thinking of the right problem.

[Adam Barrow]

Matt,

 thanks for the interesting perspective. My most flown aircraft (Parkzone T-28) doesn't have a wiring issue, I can get airborne in a matter of minutes. I'll see if I can get some pictures of the setup to share. In general, I'm able to create an 'install base' for the autopilot in my aircraft and after the initial setup replacing the autopilot has been easy. I'm also fortunate enough to be able to select airframes with a decent amount of space in them, so I may just have been really lucky so far.

My problems are two fold: 

First, I can't get the version of MatrixPilot I want to work with most (MatrixPilot_AUAV3) to develop on my (preferred) MacOS environment. It seems to be an issue with differences between the C30 compiler and the XC16 compiler, but I just haven't had the time to sit down and investigate further. If that is really the case, I'd potentially have to persuade the other developers working on the AUAV3 branch to update their compilers too.

Second, my SIM (HilSIM and SilSIM both) environments aren't stable. I can build and run both, but the simulated aircraft in XPlane does not have repeatable behavior. It will generally "fly" from the UDB (my control inputs have effect and I can see that the plane does correct its attitude somewhat). I've tried using the Cesna (as suggested by someone earlier on -- perhaps Ben?) and the default  Cirrus with basically the same result. I don't know if this is a reflection on my inability to tune the gains in MatrixPilot, the setup with XPlane / *SIM or something else altogether.

There are a few smaller obstacles I can honestly live with, or perhaps they become more worth solving after these two are addressed.

Regards,

Adam

--
You received this message because you are subscribed to the Google Groups "uavdevboard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Peter Hollands]

Matt,

To me there are two primary areas where we do not yet really seem to understand the problem, and deliver a good solution.

1). Creating an accurate probabilistic view of reality from multiple sensors. We do not yet have a good architecture for that in MatrixPilot. It will become more important over time. In detail today, we want altitude delivered from GPS, Barometer and Sonar. How best to form a picture of reality from those ? At the other end of difficulty:  we do not yet integrate vision into the IMU's view of orientation, and we do not integrate vision into location. I look forward to one day having the time to finish this course by Sebastian Thrun on the driver less car.

2) I would like to see a unified model for navigation and flight using an understanding of the forces that can be manipulated on an aircraft. Such a model will fly a Quadrocopter or an aeroplane just as well, because it is based on Force = Mass * Acceleration (and the equivalent for rotation), and understands the flight dynamics of the aircraft. I am excited by your work on your branch of MatrixPilot because you have started down that route for sailplanes. (You now incorporate Coefficient of Lift, and Coefficient of Drag into your navigation and flight algorithms). In truth, the one model, could potentially work for many types of aircraft. Our autopilot could then fly an aircraft that was both a plane and a quad in one structure, with relative ease.

The core problem in this second model is the mathematical representation. At any one time, the navigation of the plane needs to describe all the sets of solutions (potentially infinite sets) initially, and then apply constraints (e.g. fly upside down, do not exceed max velocity, do not exceed minimum velocity, arrive at waypoint at time T, do not roll more than 30 degrees), to reduce the infinite set of solutions to a smaller set. And then finally incorporate a cost model (e.g. fly with the least energy loss), to come up with the optimum navigation solution. So for me, I'm interested in the mathematical model of how all of that can be represented. Crack the maths, and software will fly the plane without lots of special caveats and a spaghetti of different code paths, which is how we do it today.

Best wishes, Pete

[Adam Barrow]

Phillip,

 thanks for the suggestion. That's interesting, on my Windows laptop (WinXP 32bit) I've been able to use both MPLAB 8 and MPLABX with the Pickit 3 and haven't noticed any issues. I did notice that the universal programming utility which was installed with MPLABX won't verify the chip after programming it but the board operates as expected so I think it must be something with that tool.

Unfortunately, I wasn't able to compile the MatrixPilot_UDB5_WJP branch (either the MatrixPilot-auv or MatrixPilot-auv-mv projects). I made sure to update the working copy from SVN (I had started to try getting it to compile before) just in case, but still no joy. I'm using the XC16 v1.11 compiler on 64-bit MacOS for reference. Interestingly, the two projects fail at different places in the compile, both linker errors, which leads me to think it's probably a difference in the libraries between the build environment.

I am able to compile the MatrixPilot_AUAV3 branch using my Windows XP laptop, in both MPLAB 8 and MPLABX (as long as I use the c30 compiler!). My 'hurdle' is just that I don't really like the laptop as much, it isn't the machine I'm mostly on and the battery is shot (I like to do my hobby coding at the end of long bike rides). I also can't use it to do testing from the field, since only one of the fields I fly at (and the one that is least forgiving about 'experimental' aircraft) has power available.

When you say that MatrixPilot_UDB5_WJP is "almost flight ready" which project are you running from? One of my personal goals is to help get the AUAV flight tested sooner rather than later and I'd like to help out with that effort. Besides more testing, I have several different airframes and HILSIM setups to use. To that end, would it make sense to start keeping a log of the AUAV "flight readiness" somewhere? Perhaps a new wiki page for the AUAV hardware with a table showing the tests we've each performed and what is outstanding?

Regards,

Adam Barrow

On Apr 25, 2013, at 7:01 AM, Phillip Kocmoud <pkoc...@gmail.com> wrote:

Hi Adam,

Can I make a suggestion? I also struggle with running both MPLAB8 and MPLabX on my computer. Only 1 seems to be able to be installed if I want my ICD3 to work. Per the manufacturer, it should work and they make a program to allow switching, but it does not work on my machine reliably.

To get around this, I leave MPLabX installed on my native machine and use a VM (VirtualBox) Windows XP computer to develop in MPLab8. I only introduces minor difficulties. If you need help implementing this type of solution, let me know. I could have this running here in about 1 hour, 2 if I had to download the ISOs. Virtual Box is free and has a Mac Version.

Also, you might want to use MatrixPilot_UDB5_WJP as it build in MPLabx and runs fine on the AUAV3 and is almost flight ready. The MatrixPilot_AUAV3 has some cool features, but is very experimental.

Let me know,

Phil

[crashmatt]

Adam,

Thanks for sharing your problems.  I don't expect many people to have the same wiring problem that I have.  My setup is fairly unique.

I suspect that the bug you have has been solved.  We know we have a problem effectively communicating what we already know.  Solving that is just not fun.

Pete has become a mac user so you might get some common problems there.

We also have a problem with trying to support too many different platforms and development environments.  We are not a large developer group and we are spreading quite thin.

Regarding your sim problem.  Ease of use is an issue.  MatrixPilot is not ArduPilot.  Ardupilot has a mass of user friendly tools and excellent help guides to get people started. What MatrixPilot lacks in shiny features it gains in creativity and flexibility.   The trick is to do the things which are creative and help ease of use.

My aim of this conversation is not to prescribe rules, regulations and tasks at the developers and users.  My aim is to take an honest look at saving some wasted effort.

It has been a while since I saw any conversation from you.  Great to have communication again.

Regards Matt

[crashmatt]

Pete,

I completely agree that we have a problem with data fusion.  This is one of the contributing factors towards us not having earlier support for more sensors.  It stopped me from investigating the barometer earlier.  I still don't have it running.

On your second point, making it easier to experiment with these new algorithms is important.  If we can reduce the time cost of implementing new features, we can do more of it.

I am trying not to discuss solutions here.  It is really tempting to jump from problem to solution.  What I want to do is step carefully from problem to root cause.

Regards Matt

[Phillip Kocmoud]

My problems are with the ICD3 device and the different versions / device drivers.

Project status:
https://code.google.com/p/gentlenav/source/browse/branches/MatrixPilot_UDB5_WJP/MatrixPilot/MatrixPilot-auav3/projectStatus.txt

This is the only MPLabX project that I know for sure compiles:
https://code.google.com/p/gentlenav/source/browse/branches/#branches%2FMatrixPilot_UDB5_WJP%2FMatrixPilot%2FMatrixPilot-auav3

Let me know if this is what you are using and / or if it works.

Phil

[crashmatt]

Another example:

While coding up the fbw branch, I was continuously struggling against data range problems.  Scaling variable up and down was a huge effort sponge and a potential source of failure. The solution was a combination of Q16/long and 16bit floats. This made the code development much faster.  There are significant down sides which means that this is not the best solution.  I suspect I know the right solution but maybe I am trying to solve the wrong problem.

Regards Matt

[crashmatt]

Phil,

A very similar problem to Adam.  Did you know that you were both trying to do the same/similar thing?

Regards Matt

[Phillip Kocmoud]

Hi Matt,

Yes and No, I am running Win 7 x64. I have just been down a similar road recently. I have a working solution to my issue so I am offering what help I can. Also, I want to see the AUAV3 succeed, so any additional developer help or feedback is always welcome.

Phil

[Tom Pittenger]

As far as the MPLAB 8 vs X issue goes, at this point I feel the entire team should migrate to MPLAB X. It has finally matured enough that it is a very stable IDE and it will simplify troubleshooting and greatly enhances the programmers ability to program. Netbeans, which it is based from, is a real IDE while MPLAB 8 sorely lacks most modern-day IDE features. 

-TomP

[crashmatt]

Tom,

I agree. I am one of the few users that still had issues with mplabx. I will get over it.

You also have some pretty massive challenges that go way beyond mplabx.

The greatest recent solution had been Bens silsim work. That has accelerated development by a giant step and enabled us to move to other processor platforms.

Regards Matt

[Mark Whitehorn]

Hi Adam,

I've been working on mplab-x project MatrixPilot-auav3 in branch MatrixPilot_UDB5_WJP. Status is in MatrixPilot-auav3/projectStatus.txt

as Phil says. Goal is to get both UDB5 and AUAV3 flying with minimal changes from trunk. I'm using PICkit3 for flashing.

Please let me know what kind of linker errors you're seeing so that I can determine whether there's something wrong with the project config.

Thanks for the offer to help with testing; I haven't yet flown MatrixPilot on a fixed wing craft and haven't started using HILSIM or SILSIM either.

73,

Mark

Project status is in 

[crashmatt]

To summarize our problems so far:

1. Easier Data fusion. Improving the flexibility of adding new information and making decisions with it.

2. Better ways of information sharing

3. Reducing wiring harness

4. Quicker development time (including algorithm development)

5. Quicker test time

6. Reducing the number of platforms

7. Making changes of platform less significant

There are a few more big problems I can think of from group conversations:

1. Future proofing

2. Failsafe

3. User safety

4. Board/feature modularity

5. Copter vs fixed wing versions

Getting back to the advice from Mr MacCready. He found ways to fail quickly. HILSIM is a perfect example. Another feature of failing quickly is the ability to re-configure quickly.

The next step would be to prescribe solutions to these problems but that is not fun. I will stop here.

Regards Matt

On Thursday, April 25, 2013 7:59:23 AM UTC+2, Pete wrote:

[Coby Leuschke]

FWIW, I am planning on getting back to VTOL work in a month, so that probably slots in at number 5 on the second list. 

And an anecdote... I just hosted Moses for a month (the young man from Kenya that started the java GUI for UDB config) and we both still agree that we prefer UDB over ardupilot. But he went back with ArduPilot gear with two Nurfs so he could do a demo for a wildlife conservation project.  I am looking at the list and trying to see if there is anything that stands out as to why we went with ardupilot for the demo....

Really about reducing our risk as we needed something fairly plug and play with decent GCS integration. The Mission Planner with config via USB and zig bee, plus support for an Android GCS were probably the biggest factors.  It takes some time when you start trying to integrate a payload and actually architect a system that can be used in the field by non experts.  We have no doubt the fantastic work that Bill and all devs are doing flies the plane better, it just seems harder to get there from here at this point.  I had hoped that we could find the time while Moses was here to start working on the operational end of the UDB but we did not.  All I can do at this point is provide feedback and hope its considered in your roadmap.

R

Coby

[Philip Giacalone]

Would it be beneficial to have a high level, logical API for the UDB? 

The idea would be to expose the internal IMU data, representing the state of the flight vehicle, while hiding the implementation details. This would allow for future UDB implementation changes without impacting integration with external systems. Perhaps a first implementation could be a read only API, allowing external systems to use the data but not change it? So we'd have logical functions like 'getAltitude()', 'getRateOfClimb()', etc. This would also make it easier for new developers to use/integrate the UDB without having to understand the internal details. Sorry if this is a crazy idea, but coming from a high level s/w background, this seem kind of natural to support integration. 

Best regards,

Phil

[crashmatt]

Coby,

Many thanks for your input.  Mission planning and configuration is a huge topic that I had missed from the list.  I had touched on it from Adam's comment but not in this flavour.

I agree with Moses with going for ardupilot to reduce risk and get the job done.  MatrixPilot does not have that rich support. 

If we can learn how to do innovative things with MatrixPilot while also being able to support it with field configuration tools, then we will have a much easier time of it.

An example:

Ardupilot is based on PID control. These parameters are changed through mavlink. This is no big problem for matrixpilot, we can do that.  The problem for ardupilot is that mission planner and every other gcs has a specific page for tuning PID gains.  They are stuck with PID control because that is the way it is done.  The mission planning is also quite limited for a similar reason. It might be plug and play but what you are plugging in is not what we want.

MatrixPilot on UDB3 is very restricted on resources. This caused some necessary but quite twisted optimizations and greatly limited innovation in some directions.  Now we have more resources, we have opportunity to untwist some optimizations in favor of faster development and features. The big question is, what are the twisted bits?

Untwisting our existing architecture is painful.  It hurts because you can destroy man-years of work and testing.  Once it is done, the community might not accept the change. The bigger the change, the bigger the risk.  In this case the size of change is considerable.

Regards Matt

[crashmatt]

Phil,

Good point.   We have a pseudo API hidden as globals used to reduce resource requirements.  The IMU might benefit from tidying but it is certainly not the worst problem.

You might think of a hardware abstraction layer as being a similar issue. To some extent we already have a HAL because Ben was able to move platforms. 

I would put your suggestion under "quicker development time".    It is a solution to the more fundamental problem.

All,

To be clear, this is not a traditional roadmap discussion.  The aim is to understand what the fundamental problems are. Your traditional roadmap requirements are most welcome since they give us clues about what we really want to do.

Here is the updated list:

1. Improved field configuration

1. Easier Data fusion. Improving the flexibility of adding new information and making decisions with it.

1. Improved flexibility between different aircraft types (copter vs fixed)

1. Better ways of information sharing

2. Reducing wiring harness

3. Quicker development time (including algorithm development)

4. Quicker test time

5. Reducing the number of platforms

1. Making changes of processor platform less significant

2. Board/feature modularity

3. Future proofing

4. True failsafe compatibility

5. Improved user safety

[crashmatt]

I missed the #1 most obvious problem:

1. Easier to use

1. Improved field configuration

2. Easier Data fusion. Improving the flexibility of adding new information and making decisions with it.

3. Improved flexibility between different aircraft types (copter vs fixed)

4. Better ways of information sharing

5. Reducing wiring harness

6. Quicker development time (including algorithm development)

7. Quicker test time

8. Reducing the number of platforms

9. Making changes of processor platform less significant

10. Board/feature modularity

11. Future proofing

12. True failsafe compatibility

13. Improved user safety

[Nikolay Arsov]

Hi guys,
Here's my two cents on the matter:

The complexity.....

Todays autopilots are too complex. As more complex they are, the less guys will use them. Last few years I observe a strange race towards complexity ....why....do we need such complex devices? Overcomplicating not always lead to a new super quality. More, overcomplicating always lead to less reliability.

I think we could design much simpler devices, still good enough for the purpose.

Modularity ( distributed I/O ).....

I think it's time to take off the IMU load from the CPU. Most of the professional IMUs have their own MCU ( fusion ) and are separate devices.
Such separated IMU+FusionMCU could be easily realized over less than a square inch board. A high speed serial interface could reduce the cable set to 4.
More, such a board could also carry the GPS module.....not 100% sure it's practical...have to think a bit.

Wire harness.....

The autopilot board could be easily unloaded from wires by using PPM_IN and PPM_OUT, instead of PWM inputs and PWM outputs. I think the servo board
should be separated from the autopilot and have just 4 - 2 for optoisolated data stream and 2 for powering. There must be onboard DC-DC Buck for powering the servos.
Thus, the servo board could be as small as 25 x 35mm. and placed anywhere inside the plane.

Easier to use ( something like Plug&Fly....????....maybe...why not? ).....

Most of the guys in forums always ask whether the AUAVx is P&F ( plug and fly ).....yes, I'm not joking. All we know UDBs and AUAVs are not P&F devices,
but as most of the pilots are looking for user friendly programmable autopilots, I think we have to point towards this. At least a good looking configuration software and a USB bootloader could be a good starting point.

( rem:.....please note I could give my suggestions just for hardware as I'm an infant in programming )

Best regards
Nick

[crashmatt]

Nick,

Thanks for taking the time to commit some good ideas.

I agree with reducing complexity.  Where do you think that the autopilots/systems are getting too complex?

Complexity and ease of use are often in opposition.  For example, constructing a good user interface which hides low level decisions has huge complexity.  Take Bill's wind estimation for example.  It appears to be simple, improves performance and removes the need for a direct airspeed measurement.  The actual maths is the complexity that is added.

Ease of use means different things to different people.  Example:

For a quad user, ease of use is having all sensors in one package.  For a fixed wing the demand is often distributed sensors.

Modularity + processor 

This is a complex topic with many arguments.  First some questions.

Is the processor really running out of capacity to run IMU and autopilot?

What extra capacity can we add to the existing processor?

What extra things do you want the autopilot to do?

If we change to a different processor, what capacity could that have? Do we need two?

If we added a second processor running an operating system, how many people could take advantage of it?  What size of processor would it need to be?

Are the older autopilots limited by the processors that they chose at the time?

More later, I need to go shopping

/Matt

[Nikolay Arsov]

Hi Matt,

I don't mean a different processor....I like this one ( EP ). I think the EP series are flexible enough and should be enough for the purpose.
As I mentioned before, there is a trend of using higher level processors, which I think useless for the moment. The MCU is not running out of it's capacity,
but who knows.....just look what the guys are incorporating recently - LEDs, sonars, TCP/IP modules, Bluetooths....etc.
There's a question we have to give an answer first - what devices we really need....and better what are enough....and maybe how many and what we'll support?

About the RTOS....I like the idea......soon or later we'll go for it.

About the modularity....making the IMU a separate device won't affect the multis as is won't be larger than a GPS...more...it could also integrate a GPS.
At the moment many of the multis are carrying the GPS at the topmost point of the shell.

About the servo power board, on my opinion it would be more convenient to be a separate device for fixed wings, but not good for the multis.

Thinking of cable harness, hanging the autopilot with any devices increases the harness too much. This becomes something like a vicious circle.
The users want to have more and more external sensors, and at the same time reduced cable harness.....no way.....

...And yes.....you are absolutely right that we have a complex topic with many many arguments, but I'm sure we all could get to the right decision.
Don't you think it is a good idea to place a spreadsheet in Google where the good ideas could be placed. I think this is the only way the users could place
their requirements and proposals.

Best regards
Nick

[crashmatt]

back from shopping.

There are good reasons for moving to a different processor (not mchip) but there are plenty of bad reasons also.  Just keeping an open mind for the moment.

Having the IMU and autopilot all in one place is very convenient for the software.  

Wiring harness

This does not just include the servo connections.  Connecting sensors is also a burden.  PPM does half of the job and doesn't have particularly good benefits.  The obvious step is CANbus but that is an enormous step.  This is the very reason I started this conversation.  If I don't know the problems, why am I trying to make solutions?

For most people, PPM means adding a converter from PWM.  I had to do this in one aircraft so that I could assemble it.  In another aircraft it just causes more wiring mess.  Different cases, different needs.

Power solutions are also a very wide choice with many options.  Trying to integrate more power functions is tricky.

Easier to use

We are a long way from plug and fly.  As features are added, options.h becomes more complex and options handling GUIs can't track the changes.  Options.h is just the start, there are now many options that are in different options files.  The trend is for many more options.  If we can solve how to remove this problem or have the GUI easily handle new options, we might get closer to PNF.

I don't think a "good ideas" spreadsheet is a good idea at first.  As the title says, "The problem is that we don't understand the problem".  A better idea is a "problems spreadsheet".  You do get to solutions but only after the problems.

Another problem is that formalizing this takes the fun away.  Sharing problems feels good but generating actions from it is plain dull.  What I don't want to do is stop people from getting creative with technologies because they just get a kick out of it. This is why I am reluctant to take this topic further than identifying problems.

Thanks again for the conversation. 

Regards Matt

[crashmatt]

Two more:
Rapid prototyping
Sensor/peripheral bus architecture and support.

[crashmatt]

A quick chat with Pete brought up the topic of diverging branches again.  He noticed that trunk is getting very little attention while branches have much activity. Not much of the branch work is getting back to trunk.  I agree.  My branch is no exception and has even escaped out to github.

The question is why this is happening.  We had a couple of ideas about why this is happening.

First is architecture.  If we find trunk too difficult to work with, we need to stay away from it.  We face challenges when adding new functionality, testing, and isolating existing code from being modified.

Second is limitations of SVN which prevent us from merging back to trunk easily.

Again, no solutions here, just the problems.

[Adam Barrow]

Mark / Phil,

 thank you. I wasn't sure how current the projectStatus.txt file was. Do you mind if I also add comments to that as I work? I'll probably put my initials or email address on the line as well, just if there are any questions.

I just updated my copy of the MatrixPilot_UDB5_WJP branch and it compiled fine on my Mac (MPLABX and XC16) so I'm back in business. I was able to program the board and a quick flight in HILSIM tells me the core functionality (MatrixPilot took control of the aircraft) is working, although I still need to find the right gains (or something) with HILSIM.

Regards,

Adam

[Mark Whitehorn]

Hi Adam,

It would be great if you make comments on project MatrixPilot-auave using its projectStatus.txt

I'll do my best to keep it up to date with code status and plans, but you must also keep up with the SVN commit messages for specific changes (and caveats) at each revision.

Very glad to hear that it compiles cleanly on OSX. Which version of XC16 are you using?

73,

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "uavdevboard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/uavdevboard-dev/syTHbhu54eA/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to uavdevboard-d...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Mark Whitehorn
kd0...@gmail.com

[Adam Barrow]

Mark,

 sorry, the compiler version would have been very useful. I'm using XC16 v1.11 (updated my environment just last week, so I think it's fairly current). Since terminology can sometimes be different, I would like to point out that there are several warnings when compiling (mostly "Taking the address of '***' may require an extended pointer for this device" which I need to research more) but the code does compile and at least passes an initial test.

Agreed on the SVN commit messages; I've subscribed to the GoogleCode commit feed, which sends me an email on each commit. While I have big plans for the AUAV, I want to start with 'basic' tests, so I doubt I'll have very much to add in the 'plans' department, but I do plan to add my successes in the project status file.

Later,

Adam

[Phillip Kocmoud]

Hi Adam,

We are aware of that warning and Mark has made a code change to prevent the problem from occurring, but the warning still exists.

Phil