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.

I've already touched on this. It can be used by pretty much any I2C device on probably any .NET Micro Framework device.

My work -> A derivative of Pavel Bansky's I2CBus class, but implements the singleton pattern (because it should be implementing the singleton pattern since you are supposed to only have one instance of the I2CDevice class.) You really might want to explore using the singleton pattern so that you guarantee that there is only one instance of the I2CDevice being used by your I2C devices.

I used this in the Bosch BMP085 Digital Pressure and Temperature Sensor

FYI my singleton implementation of the I2CBus class is being used in several projects with as many as four I2C devices on operating on the same bus.

phantom I just finished reworking my quad project to including your I2CBus, works fantastic! I really like this approach, elegant and simple.

Cheers!

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

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...

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...

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 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.

Well, not as good of new as I would hoped, watch around 1:20 for the best performance as of right now. Still not hovering for me but I think I'm having transmitter issues. Anyways as you can tell from the video I wont be flying again for a bit.

i thought we were a bit more stable, we still have some work to do then

I add much more success last night, I've had a few hard crashes so I need to spend some time on the hardware.

Brandon, you may want to avoid making multiple posts in a row. It makes it very difficult to read the thread.

As for DR&Expo, if you have a computer radio, you can program that in.

I recommend you get a computer radio so you can switch back and forth between multiple DR&Expo settings. I use gentle settings for departure and tighter settings for cruising.

Chris, you may want to avoid being a dbag too many times in a row. It makes it very difficult to read the thread.

Move your _coefficients.Length statement to it's own local variable, before you loop and then reference that. It's much faster in netMF than referencing the property.

Also, underscores are against most best practices for .Net

Hey Mark, good catch i didn't even notice I did that. Also the _privateMember or m_privateMember is apart of most c# coding standards I've seen.

While we are on the issue, I was thinking it might be nice to have a cheat sheet with major .Net features, and the performance hits involved. One this that has stood out to me is that the ms code rarely uses properties, relying on public variables instead. It would be nice to develop our own "Best Practices" especially as it relates to pseudo real-time code. One of the major things I seen thrown around a lot is this concept that you can never know how long .Net is going to take to execute any given line. I think with enough understanding we should be able to quantify every line. This is especially important to the success of this project. Just to keep you guys in the loop, I had a major hardware failure (blew out the bearing on a motor) that has stopped me for the moment from trying to fly again. I have every reason to believe that it could have actually flow. I think the only thing that was stopping me from doing so was what Seto and Mark both identified. Seto if you do have a quad that you would be willing to try on .net and an extra MCU I could provide you with the tools to get running on my platform. For that matter if anyone else out there is interested let me know and I will put together an architecture of how it works. That being said I did put in an order for replacement parts this morning, so hopefully i will be back up soon.

Oh sorry I was under the impression you had been flying already.

Brandon, I think you're reading my comments in the wrong tone - i meant them as a general comment, not targeted at anyone specific. I'm an Aussie, we're pretty layed back and chill - if in doubt, just read my post as a layed back view point

Please feel free to take a look at these links:
IDesign have an exceptional coding standard for C#, which a lot of companies I know of base their standards on. These are basically an expansion of Microsoft's:
http://www.idesign.n...ng Standard.zip - zip with PDF.


This is what Microsoft use internally: http://blogs.msdn.co.../26/361363.aspx

The guideline for creating class libraries is a rather informative read: http://msdn.microsof...y/ms229042.aspx

And this is the book I mentioned (which I recommend every developer - professional, amatuer and enthisuast alike read) - http://www.amazon.com/dp/0321545613/ - on on Book Depository if you're not in the USA (free shipping! woo) http://www.bookdepos...sign-Guidelines

IDesigns C# standards (my personal favourite), section 1 point 4:

Prefix member variables with m_. Use Pascal casing for the rest of a member
variable name following the m_.

public class SomeClass
{
   private int m_Number;
}

Are there any schematics how to connect the "Dataconcentrator"?
I've taken a deeper look at your framework, it's a good piece of code.

I've added some code to support my peripherals.
I just need an arduino for the Dataconcentrator.

Hey zerov,

I don't have any schematics (it's all just proto'd right now), but at a basic level you will just need to interface your arduino (or any other realtime mcu), and the netmf board over I2C. I used this logic level converter to get them talking: http://www.sparkfun.com/products/8745. It's not actually strictly necessary to use the level converter between the arduino and you netmf board as they are usually 5V tolerant, however since I put the gyro and accel on the same bus you will need the converter(they are 3v only). I will attempt to put together a diagram of how I have everything wired up this weekend.

-Luke

I see why you use the Arduino to get the radio data, but why the motors are connected there too? Haven't the Netduino and Domino/Panda native PWM pins? I wanted to use the PWM's on my FEZ.
...
What do you think?

Yeah you noticed that eh? I originally was going to use my arduino as the flight control board. It was just easier to relay motor command over I2C. I actually just finished rewiring the shield so that the pwm pins come from my fez panda directly. So you totally had the right idea there.

So now the razor. Ultimately creating code for interfacing with stuff like the razor is something we want to do, we're just not at that stage yet. Wasting 3ms on parsing the razor's ahrs code is really a waste though, and really from everything i've seen about multicopters so far 50Hz is not gonna be nearly fast enough. You could totally re-write the firmware to get spit out raw data across serial on a demand basis and if you need help i can provide it. My personal recommendation is to just ditch the razor imu for this instead http://www.sparkfun....products/10321.

As far as concetrating all this data on another arduino, I think that adds too much complexity. All I really want the arduino to be is a PPM to I2C converter for the radio. I think eventually I will swap out the teensy for something even smaller.

Cheers

But if I take such a 9dof stick, I must make all the calculations on the .netmf device.
The Razor 9dof would do all this calculations:


I have binary messages over serial: [type:length in byte]

[DIYd:4][ID:1][roll:2[pitch:2][yaw:2][checksum:2] => 13byte

But how to request data on demand? just send a byte to the Razor and respond?

Yeah i would just setup a polling loop to check for an incoming message, then provided the data. and honestly you are providing the data so frequently I dont see any value in doing checksum calculations either.

The reason I don't want to be doing calculations on an external board is it reduces accessibility to the code. Principally we want to be able to plug and play hardware, with all control logic being done on the .netmf device. To be honest if your not gonna use the .netmf device to do your control logic then why use it at all. The additional arduino is for convenience, eventually I would like to move to native solution for handling the radio ppm stuff.

Ok so I have a new issue I'm wondering if anybody has any ideas. Right now I have the netmf board being powered directly off a bec from one the escs. I recently rewired the shield so that the PWM signal now comes directly from the netmf board, instead of the external mcu I was am using to convert the radio PWM into I2C registers. This creates a new problem as netmf takes a couple of seconds to bootstrap and initialize the pwm outputs, and the escs require a 0% signal to bootup properly. I realize that I could solve this by powering the netmf board directly from the battery and power on the escs after the board is initialized, but I prefer to not add extra complexity for powering on the unit. So right now the solution is to power the netmf board on usb to let it bootstrap, then add battery power a couple seconds later to allow the escs to boot properly. Any ideas?

A pull-down resistor on PWM output?

I'm not sure what that would do. The issue is that for the escs to boot they want to see a 0% signal (1000 us pulse, or whatever they have been calibrated for).

A pull-down resistor pulls the output to ground - so, there will be 0% PWM output (logic low) during Netduino startup (when the pin is floating high).

Your missing the point, 0% output is not logic low, 0% output is a pulse lasting 1000 microseconds every 20 milliseconds. Holding the pin low would not do anything.

I see - sorry for my misunderstanding.

No problem I didn't mean to be rude in my response. Actually thinking about it though it might be worth a try. I wasn't thinking about the fact that the pins will float during startup, I'm gonna try this anyways it might actually be a solution. Given not what I was thinking of, but I will report back if this works.

Cheers

If you are at all concerned with speed and/or the gc, you should try my approach:

When dealing with bit conversions always use the Utility class, for instance working with floats:

public static unsafe float ToFloat(ref byte[] buffer, int offset)
{
   uint value = Utility.ExtractValueFromArray(buffer, offset, 4);
   return *((float*) &value);
}
public static unsafe void ToBytes(ref byte[] buffer, int offset, float value)
{
   Utility.InsertValueIntoArray(buffer, offset, 4, *((uint*) &value));
}

Note that the name ToBytes isn't exactly accurate as normally a bit converter would return the array, but usually you are using this to pack data in a long buffer, and using the reference saves the additional hit for making a new array.

or how about a double word sized variable:

public static long ToLong(ref byte[] buffer, int offset)
{
   long value = (long)Utility.ExtractValueFromArray(buffer, offset, 4) << 32;
   value |= Utility.ExtractValueFromArray(buffer, offset + 4, 4);
   return value;
}
public static void ToBytes(ref byte[] buffer, int offset, long value)
{
   Utility.InsertValueIntoArray(buffer, offset, 4, (uint)(value >> 32));
   Utility.InsertValueIntoArray(buffer, offset + 4, 4, (uint)value);
}

Obviously you could adapt this for any other types you require. These are just what I use in my current project.

Cheers

The fist thing that jumps out is you specified address 2 and 3 in you post, but 0x29 in your code. If the address is supposed to be 2 then cahnge the first line to : I2CDevice i2c = new I2CDevice(new I2CDevice.Configuration(0x02, 100));

Hi guys,

I am looking for a ATmega 328p programmer. The reason is that my 9dof from Sparkfun has (apparently - what a bummer) a flawed bootloaded and needs to be reflashed.
Thus I am wondering if you have any recommendations (possibly being available in EU).

I guess I'll have to solder SPI pins as well. Just great

If you already have a spare arduino you can reflash the arduino bootloader like this:
http://arduino.cc/en...rial/ArduinoISP