Brandon,

I'm honestly not trying to be pessimistic, I am simply trying to be realistic about the capabilities of NETMF and the hardware at hand. I have a very large amount of experience working with embedded devices and and I also have a very respectable amount of experience implementing, debugging and tuning control loops in autopilot applications.

The thing about quadcopters is that if it fails, it will fail spectacularly, at least resulting in damage to props, probably more. I have actually killed PCBs in quad crashes before due to the intense force involved.

I can certainly understand your enthusiasm in implementing such a system within something that flies, however I may recommend that you practice your EE skills on something that doesn't have the ability to single handedly destroy all hardware involved, not to mention inflict bodily harm (a 12" prop stuck in the wall is not fun...). I'm not saying that you shouldn't do a quadcopter or obey my advice, either, however I would recommend that you seriously consider the limitations of the systems involved.

If you really want to develop autopilot applications in C# .NETMF, I might also recommend that you look into doing it on something like an RC car/boat/hovercraft, etc. All of these are very appropriate for NETMF and I personally have a NETMF powered RC car autopilot project. It's more fun than it sounds and you can always do other stuff like cruise control, etc.

Otherwise, feel free to ignore my advice and proceed. I'm only trying to help

Chris,

I think the point is we alredy are proceeding, I have been flying on .net for the last two days.

I just recently started porting my quad based on Aeroquad to GHI's FEZpanda board. I currently solve my realtime problem by offloading to a arduino ported teensy. I got so excited when I started reading about the possiblility of running native code to handle everything on the one board that I bought a netduino from Sparkfun. Unfortunately its gonna be 3 weeks till it gets here (on backorder). I would be very interested in collaborating on a project such a yours.

Hello Brandon

I am interrested by your project, i would like to read your code but i can't access google site and tortoise say "Forbidden
Your client does not have permission to get URL /p/quadnet/ from this server."

it's my fault (bad client or bad actions) or it's because you should give me a read acces before ?

Thanks a lot

Gilles,

Currently the project is not posted but we will be going live soon, the new project site is available at http://dotcopter.net/

So I've been going through the code and got hung up here: PID needs to remain double accuracy Gyro also needs to remain double accuracy I'm not sure how to fix this using AircraftPrinciplaAxes.GetReading() as seperate calls for each axis won't work as you call the Update each time which would result in 3x the I2C calls, same goes for the radio In my implementation the radio is actually an I2C device but in most cases this would be ppm read so native code will need to be added for that lastly in my experience with .net so far I found to minimize the frequency that the GC runs at I minimize the objects that I create during the control loop ie. that AircraftPrinciplaAxes object. It might just be that the size of this project is much bigger than what I was working with but the GC is running 5x as much as it does with FEZiquad but we are basically doing the same thing. also just as a note, i wrote feziquad over the course of the last week, i'm not particularly attached to any of the concepts used I just wanted to fly my damn quad. I really like this style of programming but I am completely unexperienced in this style, just thought you might want to know that before you start letting me muck around...

I would highly writing the control code in native code, and then just calling into it for "command and control" purposes. Basically, the native code does the stabilization and maybe the radio control (so it doesn't go in the wrong direction) but then C# handles the rest.

What is the rest (the part that's not in the control loop)?

Chris

Chris,

You make my point exactly: What is the rest?

If we take the control loop out pretty much nothing and we are looking at Aeroquad ARM. I just wanted to put this out there:

I learned assembly on ARM, I specnt a lot of time in school writing for ARM. Granted I haven't been doing much with that for the last few years, if I truly wanted I could just make Aeroquad ARM version. I think we all need to re-examine our motivation here. For me there is only one reason to program in C#; intellisense. Cheap(free), fast, and good all at the same time(to counter-point my tag line), thats what I want to be able to offer.

I started my quad by working with Aeroquad, then I snapped my arduino in half in a crash. So I decided to try to port to this awesome teensyduino I had laying around. Needless to say that was a chore, after a couple of weeks I gave up. I came up with a new idea, try it on .NET. At the time picked GHI's offering due to the faster processor thinking that would help offset some of the slowness. But that's not the point, the point is I flew one week later. In all my tests so far I have never experienced some sort of instability in .net, granted lots of instability in my control code.

So if you couldn't tell already, my vote is keeping as much as we can in .NET. Drivers are native, drivers are always native. If the firmware is missing something we need (ie reading pulses from the radio), then lets put it in. Edit: (I meant native code in general, possibly Cory's approach) There is only one reason I could write FEZiquad in one week and have it fly, because its .NET.

Anyways I just wanted to get that out there, hopefully we can start off with this goal in mind.

Brandon I was just out fishing on my way home, were you able to figure out the issues with your repository I wasn't able to access it last night. It asks me for user name password. I will get to work implementing your methodology, commit when I'm done and maybe put up a video if she flies. Edit: Nevermind i got your PM, smartphones are useful but mostly tedious...

Brandon, hows the weather over in Van? lol always great to work with the best... I'm working with mecurial right now so I had to get subversion, installing as I type. I was reading the thread you started before on the same topic and I wanted to put the question to bed. Can you fly a quad with NETMF? Hell yes! check this out: As I alluded to previously its not totally .Net as the receiver stuff just isn't possible. But there you go. I agree basing off aeroquad is going to be the way to go, in fact that is what I have base FEZiquad off of. (Don't laugh I needed to call it something) The mecurial repository is available on google code: http://code.google.com/p/feziquad/ Well thats all for now, time to start checking out what you've got so far... Edit: Actually there is one other thing, what is DDD?: this http://www.gnu.org/software/ddd/?

Brandon, that is indeed the code running in that video

Can you offer any details up about your platform?

Wow Corey, I just has a "Duh" moment there... I guess some of us hardware guys have been spending a little too much time in .Net! Great explaination!

Sounds like your problem is a hardware related issue, can you be more specific as to what you are trying to do? Currently your saying these two pins will always have the same value. If so just use one pin.

I have a BMP085, when I was messing around with it a while ago I mistakenly applied reverse voltage to it, and now it generates very similar data to yours...

There is another way to grab execution without requiring the checking of a while, try this:

for(;;);

It looks funny but if you think about how a for loop works you can see how this basically turns into a looping nop instruction.

That said since you are dealing with an interpreted language I'm not sure if this would actually turn into an infinitely looping nop instruction like it would in c.

This makes it so that other threads may be delayed in getting access to processor time giving you a slow response and also doesn't let the chip go into a power saving mode.

It shouldn't delay any other threads as the processor is always doing "something" nop's or otherwise, but you're correct that it will increase power consumption.

Edit: This statement is unverifiably vauge