Have you flown an R/C plane or helicopter before? A common thing for beginner pilots is to give full stick corrections when only 1/10th of a stick movement is required, this leads to wild oscillating flight like you are seeing, the same as a control loop that is correcting too much at a time. Can you take off just by using throttle? If you can't, you have some trim issues which need to be corrected before anything else. You should be able to throttle up for takeoff, and hover with the flight computer keeping it still and level. Once you can do this, introduce small movements in one direction, then return to a hover. This is how beginner helicopter pilots are taught - as it saves the wild movements of going too far too fast. You may also want to consider the room you are using - make sure you don't have objects that will return the down draft to the quad creating turbulence or winds which can disturb the flight artificially.

I think you need to tone your control loop adjustments or your stick inputs down. It looks like it's doing too much and can't correct fast enough.

Whoa a month, i guess i need to stop procrastinating......

heres my ideas hardware wise, would like some opinions, you mentioned using a better BEC, so I have taken it off the list open for your suggestions, keeping in mind i am trying to be very modular is the reason for the component shield

Motor	6     $6.00      $36.00 	http://www.hobbyking.com/hobbycity/store/uh_viewItem.asp?idProduct=5354&aff=104834
ESC	6     $9.23      $55.38 	http://www.hobbyking.com/hobbycity/store/uh_viewItem.asp?idProduct=6458&Product_Name=Hobbyking_SS_Series_25-30A_ESC_%28card_programmable%29&aff=104834
Props	8     $4.00      $32.00 	https://www.mikrocontroller.com/index.php?main_page=product_info&cPath=75&products_id=256&zenid=43fb24fa5fbee9bca99cea5ee6462e48
Battery	3     $19.00      $57.00 	http://hobbycity.com/hobbyking/store/uh_viewItem.asp?idProduct=7634
Battery Charger	1     $25.00      $25.00 	http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=2055 
Frame	1     $90.00      $90.00 	http://quadframe.com/html/quad002.html
RC Transmitter	1     $60.00      $60.00 	http://hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=8992
ITG3200/ADXL345	1     $65.00      $65.00 	http://www.sparkfun.com/products/10321
Component Shield	1     $22.00      $22.00 	http://www.robotshop.ca/ghi-component-shield-v2.html
JST Sensor Cable	20     $1.76      $35.20 	http://www.robotshop.ca/inex-jst3aa-sensor-cable.html

Sorry for the double post - however my other post is so off topic it's not funny, and I worried you wouldn't read to this part.

I'd like to make a few suggestions to you - I've been flying for 15 years, and worked for several years in a hobby shop for fun as a second job. These are of course just suggestions.

For your charger, get one of these: http://www.hobbyking...=7028&aff=19701
This will give you far more options for charging batteries, which is safer - and more versatile. I bought one of these for my father-in-law-to-be for christmas. This will let you charge many different types of battery and also discharge/cycle batteries as well which can be very handy.


For your transmitter, if you don't need 9 channels get one of these: http://www.hobbyking...=9041&aff=19701 with http://www.hobbyking...idProduct=9043. This is the basic 6ch tx and usb cable. The USB cable is just a SiLabs VCP. The controller can then be programmed by software on a PC. The software is rather ugly and not very good, but it works and will save you a bunch of money.

I assume you're getting 2 motors as spares? Those are pretty crappy and you in my experience you may have a dud in the 6, so that's a good idea.

ESC's - I'd suggest http://www.hobbyking...=4312&aff=19701 - I don't trust any ESC's except Turnigy Plush/Sentry honestly. I've had a couple of planes go down in a ball of smoke (or fire) because an ESC failed and caught fire - or the PCB turned to ash from the heat. I have pictures somewhere at home heh. Your motors max draw is only 14.5A, so 30A esc's are just extra weight. A Turnigy 18A plush has Fairchild HEXFET's rated to about 22A.

Battery should be fine, that will allow you 20A/motor in a quad copter. If you're building a Hexcopter you'll need a bigger battery, or higher C rating.

Frame: That looks pretty darn tacky for $90 - i'd want a lot more for my $90 than that. I've seen similar to that for about $40. Chris Seto can probably point you at a couple of basic stick type ones for cheap, i know he did a lot of research into them a couple of months back. Personally, I'd go for something like: http://www.foxtechfp...rame-p-196.html - these are plywood which is easy to repair and it's built extremely strong - they'll take some pretty big crashes

Thanks Mark that makes sense, we need to just concentrate on throttle and throttle alone.
Chris thank you for the forum etiquette reminder. The posts were fast given we we had discovered the algo at the exact same time i replied and implemented it in code, i've attached our algo. i think you might be on to something as far as making it a scaling variable that can change as the flight conditions change.

using System;
namespace Quad.Net.Commons.Utilities
{
    public class Scale
    {
        private readonly double[] _coefficients;
        private readonly double _offset;

        public Scale(double offset, params double[] coefficients)
        {
            _coefficients = coefficients;
            _offset = offset;
        }

        public double Calculate(double value)
        {
            double output = 0;

            for (int i = 0; i < _coefficients.Length; i++)
            {
                output += Math.Pow(value + _offset, i) * _coefficients[_coefficients.Length - i - 1];
            }
            return output;
        }
    }
}
namespace Quad.Net.Tests
{
    [TestFixture]
    public class ScaleTests
    {
        [Test]
        public void TestQuadratics()
        {
            Scale scale = new Scale(-1500, 0.0000008, 0, 0, 0);
            Assert.AreEqual(scale.Calculate(1000),-100);
        }
    }
}

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

ESC's dont care if they dont have a signal when they turn on. They need to cater for there being no R/C signal when someone plugs in the plane first then realises their transmitter is off. Once they start getting PWM they will use that - and usually not the first packet either, they typically have hysteresis in them to require a stable time on the PWM. I wouldn't worry about the minuscule boot-up time. Just go with it. I regularly turn on my planes without the TX on (I know, I'm naughty).

Ok well i purchased:

4x TURNIGY Sentry 25amp Speed Controller

4x Turnigy 2217 20turn 860kv 22A Outrunner

2x Woven Carbon Fiber Sheet 300x100 (2.0MM Thick)

2x Carbon Fiber Square Tube 750x10.5mm

to build a quadcopter from.

I only really need one CF sheet, however the second gives me spares lol.

If you want to spend that much money on a frame Brandon, why not get a Gaui? In my opinion, they look a lot more solid and are cheaper. The copters at the link you sent look like they are just a moulded stick design for 400-800euro. To start with, why not get a basic stick armed quad? If mine works out i can put up the design files for printing and then cutting the carbon.

Very interesting, looking forward to seeing more information on this device!

It will be interesting to see how the quad goes purely on a Netduino. That fezzer code is Chris Seto's btw (His TinyCLR user is simply "Chris")

As a .NET developer for around 10yrs now, I am happy to support Chris in saying that no form of .NET or any managed language can be use realtime. By real time we mean that you know exactly how long something takes to a clock cycle level - and it will always take that long, no matter what.

How do we know that .NET isn't designed to be real-time? The shortest amount of time you can hold execution up for without using IL is 1ms, and the sleep can be inaccurate by as much as 2-3 milliseconds - even on full .net on a 3ghz quad core. You have no single clock sleep, no nano or micro second wait. There is no guarantee that any given method call with execute at the same speed, at all times.




.NET has always been designed to be a fast to write, easy to use, quick to develop smart language. .NET is slow, it's not going to be as fast as C, never mind ASM optimised C. .NET takes care of all the hard stuff for you - memory, object life cycle, eventing, threading, error handling, etc. This is where it excels. It is not designed to run a time-critical system such as a flight computer.

The wallstreet application previously mentioned won't mind if a piece of code runs 1ms too slow. This sounds like a minuscule amount of time - only 1/1000th of a second. In the embedded world, this may as well be a minute. When a basic dsPIC processor is capable of handling 40 million operations a second, and cheap ARM chips capable of handling well in excess off 300 million operations per second it puts things in perspective. If it takes you 1000 operations to toggle a pin (which would require some really dodgey code!) you can still toggle that pin in 1/300,000th of a second. Toggling pins is easy, now imagine some mathemetics and reading analogue inputs, taking some serial data, i2c data, etc. Say this is 3000 operations. That code can execute 13,333.33 times per second on the basic dsPIC processor.It will always execute at this speed, every single time. It will always take 3000 operations, no other operations will occur other than what you've written. In .NET, the same code might execute 2000 times a second, or only 500... it's totally random, unpredictable, and uncontrollable - this is the issue.

I didnt mean to start any kind of war here either but i must object to the radical inefficiencies that you are both speaking of, there's a difference between 20 million operations and processing 20 million operational messages a second on one thread updating a domain with 100 millions objects in memory. Perhaps this is the disconnect between hardware programmers that are hardware first software second. I am going to admit i am a noob when it comes to the hardware side but i cant imagine it this inefficient. no program i have ever made is content with a 20 second lag because of gc, thats drag and drop college kids. These are teeny objects and GC should have no impact if you are cognizant day one (which i always am). I have worked in .NET since the beta, I have run billions of dollars through .NET at millisecond efficiency(i agree on the sleep statement btw, .NET timer classes are awful), i have beat other programs to the punch($) by being more efficient and agile, these include ones written in c and c++, by programmers that are not as aware of speed given their bias of their language.

I'm not starting a war here either, neither is Chris, we're simply trying to inform you of the limitations of an interpreted language running on a 48mhz processor. We're not saying it can't be done - you just seem to think you're going to get the same pure C# performance out of a tiny little SoC device that you're used to at work/in full .net.





The financial application you are running I'm guessing is on a dedicated server with multiple quad or hex core xeons running in the 2.2-3.2GHz region, with tens of gigabytes of ram. This is a 48mhz, single chip with 60kb of ram. Full .NET runs JIT, NetMF is fully interpreted.

During the day I work on mine scheduling software. This uses complex genetic algorithms and we run our service on a bunch of 24 core Xeon blades (4x hex core) with 8gb of ram per core. With the size of the data we are processing (1-2 million blocks with all the genetic crossovers, village, population data etc), optimisations that take 10 microseconds off code execution time can save minutes. I do a lot of optimisation work and have been working with the CLR since the beginning on the full framework, as well as CE and asp.net.

NetMF is a whole different beast. I've also worked heavily with the NetMF CLR, I have a large library of methods in C# that are faster than their native CLR equivalents, sometimes 3-5x faster. I'm not a college tweenie or amateur developer, I'm employed as a software engineer and have been for the past 8 or 9 years - only working with C# in the office. I say this not to brag, but to try to give what I'm saying some weight. I know the CLR inside out, I have no issue with writing MSIL, I've published articles on C#, I know how to optimise C#. In my own time, i write C#, C and C++ on embedded systems.

A 48MHz ARM running IL natively would be fine, a 48MHZ arm running JIT would be OK, a 48MHZ ARM running C++ code that interprets IL is slow. Each IL call takes dozens, or hundreds, if not thousands of instructions (depending on what it is) to execute. You don't have the pipelining or co-processing that a Xeon or other intel/AMD chips have.

I'm not a hardware person who's learnt software, I'm a software guy who over the past 4 years has learnt a lot about hardware through trial and error.

What exactly would cause this randomness and unpredictability?

We do have the source code to this, so can we point to the spot that is causing the problem?

C# events, threading and the garbage collector (among other things) can interrupt the execution flow of your code, causing this unpredictability. Sample code? Create an application, run it - there you go. I can guarantee that you will not see the exact number of clock ticks pass for every single loop of code unless it is an ultra simple app like blinking LED's. The simple fact is, this is a managed language - you don't have total control over what happens when and how.

I too find the moon missions just incredible, the amount of work that went into hand winding memory alone is insane. You have to remember though, that was hardware designed to work with software for one specific purpose. There was no managed code haha. It also had the best hardware and software people in the world working it. Consider the Apollo computer to be similar to custom silicon, such as in a graphics card or digital slr. You wouldn't expect a micro processor to be able to do that even if it has higher specs, or if it can do it - it wouldn't do it well.

I agree, some code out there is absolutely hideous - but everyone learns somewhere. I'd hate to look at my first attempts at coding (which i probably thought were brilliant).

As far as you go optimising, i'd suggest you start with making the code as easy to work with as possible, then look for the slowest sections of code. There is no profiling on NETMF so it's pretty much a matter of knowing where it is going to be slow, making a test harness and then executing that code 1000 times, make a change, execute another 100 times, see if there was a speed improvement, rinse and repeat.

Rather than going multiple netduino's to handle the task (this is basically the mythical man month) go with a real time processor - you could use something high level such as a Propeller or low level such as a dsPIC. This would handle the PID loop (or whatever pattern you use) and take input from the netmf chip. NetMF would be handling navigation, position, etc.

I've only used the watchdog on FEZ/GHI products. I assumed it was implemented on the NetDuino.

TimeSpan ts = new TimeSpan(0, 0, 0, 0, 1);

Will create a 1ms timespan faster (object creation time wise) than your call above.

Fred,
What you actually want is to use the watchdog how it's intended - rather than just arbitrarily rebooting your device - wait until it locks up and then reboot it. Simply create a timer that executes once ever 5 seconds or so which resets the watchdog timer, and set the watchdog to 5.5-6s. If it doesn't get reset - the watchdog "expires" and restarts the device.

I too would like a native solution for this Like Chris S, i don't have the tool chain for compiling for Atmel ARM

There is a far easier way everyone has overlooked Use the watchdog service in Microsoft.SPOT.Hardware. http://msdn.microsof...y/ee436617.aspx Set a timeout of 1milisecond. Set Enabled property on the watchdog to true. Thread.Sleep for 100ms. Watchdog will reboot the device.

klotz,

A bit of both. But mostly a software limitation. If there's interest, we can start a community project to expand this to 4GB or beyond (for MicroSD cards that support SPI).

Chris

Any chance of going native on the uSD rather than using SPI so as to get the higher speed read/write?

Nevyn, it appears you've deleted the images from your server? Do you have them hosted elsewhere?

Btw Chris, i bought a book on SolidWorks for that other 4wd thing we were talking about

Lol, more it was just a convenient place to chat lol

Dirty Bits, NetMF isn't designed as a real time, high speed pin toggler, it's designed to make complex high level code simple and fast to write. If you need ultra high speed, very tight timings, get an Arm Cortex chip and program it in C. If you want to implement complex functionality that is not time sensitive (ie: a few milliseconds don't matter) then NetMF is going to get you where you want to go ultra fast. If you want to dump data out really fast, you can abuse some bitshifters and SPI to do it insanely fast - this is going to require some very good programming skills and a good level of electronics expertise however.

National also make the LM60 (and similar) series of sensors. They are extremely easy to use and reasonably accurate.




With 6.25mv/C, and a 424mv offset to 0C... you just need to take the ADC port value in milivolts (3300/ADC value) and subtract 424, then divide by 6.25f to get your reading in celcius.

// gain = 6.25 mV/Deg C 
            int mv = sensor.Read() - 424; // 424mv = 0 

            return mv / 6.25f;

Mark,
Thank you for your comments, this forum has truly tested my ability to hold my tongue and be professional.
I will try to make a point of not posting questions that expose you to my "amateur / ignorant" coding techniques shared by ms mvps and the ms clr team.


Great community we have here.

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

If you need nanosecond accuracy - eg: bitbang a protocol, netmf will not do it - raw processors of any sort will. Be it Atmega's, PIC/dsPIC, cyprus, ARM... whatever. Arduino is just an Atmel AVR remember - with some helper libraries. If you want to hold a pin on for exactly 22.45micro seconds, you can't do that on a managed system - you can on a raw micro. If you wanted to process a video stream and overlay text on it, such as AVROSD does - you couldn't do it in NetMF - it simply doesn't have the fine timings or reliability for timings that something which is done in assembly does. In assembly you can precisely count exactly how many cpu instructions will get executed, and based on the click speed and MIPS you know the processor is running at - know exactly how many nanoseconds that will take. On NetMF that isn't possible. Interrupts get raised 1-2ms late (1/1000th to 1/500th of a second late) - that is a *huge* amount of time. On top of the OSD example, how about you're using a bullet to break a light beam, so you can fire a flash or camera as the bullet hits an object. At several inches per milisecond your bullet could be long gone if you miss by 1ms. With a raw processor however you'd be having everything happening within nanoseconds...not even us... or ms... ns.. On NetMF however, you can do things that would only be a dream on an 8 bit micro in 1/100th the time it would take in something like C from scratch. NetMF offers a huge amount of flexibility and libraries and debugging support - at the cost of realtime processing.

If you need realtime processing, go arduino or just get the raw MCU and program it like a "real man" hehe. Other than that, use a netduino/netmf based device. You'll end up with more hair at the end of the day and your time to release will be much faster. That being said, every device has it's place.

_ and m_ are all well and good for C/C++ however for C# they are redundant with the IDE making everything extremely visible. There is a reason for microsoft's best practices, I'd be happy to go through them all if you wish, however it's going to be a huge post and this thread is not the right place for it. Microsoft's best practices, or some very close semblance of are used in almost every company that develops C# software that I have seen/worked with/worked at. The only people I don't see following them are: Recent converts from C/C++, Amateurs following other amateurs bad examples, total beginners who are porting tArduino code over verbatim, and finally, people who think it makes them look cool/experienced to write code like you would in C/C++.If you're basing your best practices on a forum full of (no offence intended to anyone) relatively beginner/amateur developers with only a few professionals.. well, that's up to you I guess. Most code I've seen around Netduino/GHI/netmf and especially the SFE/Arduino forums would get you reprimanded in a corporate/company environment. Just because other people do it badly (mostly through ignorance as they are beginners) is absolutely no reason to as well. Having written best practices for companies in the past, and having reviewed hundreds of best practice documents I can confidently say that Microsoft's best practices are well adhered to in the corporate world. I've looked a Philips, GE, several mining companies, banks and many other large organisations, as well as dozens of smaller companies. Best practices are there for code readability, usability, ease of maintenance and the fact that most of it is common sense. To anyone who wants to know more about C# coding conventions, I highly recommend you pick up a copy of Framework Design Guidelines, by Krzysztof Cwalina and Brad Abrams. This is an exceptional book that is very insightful on design libraries, classes, interfaces, naming patters, etc.