Good call. BTW, the quantum is a constant and can be changed in code. We've never tried increasing it but it could be possible to increase it to, say, a few weeks/months. If everything is executing on a single thread and one is not using events or threading, this could be a valuable mod.

Chris

Chris where do i change this setting?

As posted on another forum page http://forums.netdui...o-quadrocopter/ I've started a new quadrocopter project. Its just a start and I'm sure will not be easy but I look forward to working with this community to get it moving. As well I am trying to make this hardware and implementation of framework agnostic. So potentially it could run on Netduino or other .netmf boards, but of course we'll be working towards the netduino application first and foremost, it will also be run with a plug and play config so we can add in support for different types of hardware / gyros / escs / acceleometer, magnetometer, altimeter etc. PM if interested and look at the source which as it stands right now is just structure of the project that i have set up in my head.

http://forums.netdui...pter-for-netmf/

That is fantastic and may help for getting quicker results in my quad project

that video when posted on engadget is what got me really interested. there's some guys at MIT doing some cool stuff too. The one i found a lil crazy was the one that had the kinect hardware attached for object detection, which i think can be done alot simpler with less weight but still a neat concept

http://www.engadget....nType=wl-gadget

A guru buddy of mine suggested that F# would be perfect for the stab loop part of the program and saidi would be able to use F# as long as the calling assembly (entry point) was still in C#. So the C# program would call into and F# dll, since it all compiles to the same binaries it shouldnt be an issue. I would assume the same can be done with VB, listen to http://www.dotnetroc...spx?showNum=625 where they speak about VB

a small test shows he's wrong, too bad was worth a try

Magoocas, Fellow Canuck. The aeroquad software is pretty good. I've looked through a few of their classes and they've done agreat job with some of the avionics and physics concepts. A big part of what i am trying to accomplish in this project is a nice domain of those concepts, they seem to have mashed them together quite a bit, I come from DDD and want to apply that technique here. A port would be great and we can just try and organize it better. I have been inundated with my day job and my own $ making projects the last 2 weeks, but I'm about to order all my parts and start with the three gyro concept which will be just the stab part, not the full 9 degrees of freedom concepts. I will PM you for SVN repository

Yes Domain Driven Design, read eric evans and Jimmy Nillson, they changed everything

I am not a DDD expert but i try to use their methodologies

just looked at the source there for feziquad, is that the one that you have flying in that video????? the code is very simple and I like how its organized, I like alot of things in there. If thats the one thats flying i am impressed

Chris, that is exactly what we are looking for, if it were possible to get a faster line to the handlers send in delegates of our own to those handlers and was wrapped in a nice library i think we'd be laughing with a fast enough hz to do anything that can be done in arduino, therein lies the bottleneck, like i said there are ways around GC. I did some more research on F# the other day and saw how people have fooled the compiler to use VB and have found a way to do it in F# but for purposes of simplicity within this project i've decided to use C# and when i get to optimizing (if need be) might switch out some of the loops for F3 for speed.
Magoocas,
I am impressed, i think we found our starting point and might want to involve Luke in what we are trying to do. if you've looked at source control you can see the implementational way in which im approaching.
We have
the Quad.Net solution with:
Framework (contains interfaces like IPWM)
Framwork.Implementations.SecretLabs (implementations like SecretLabs.NETMF.Hardware.PWM)
This allows for us to swap out framework specific implementations, ie using fez's custom framework
Hardware (contains generic interfaces for things like motors, gyros and escs)
Hardware.Implementations (implemntations of hardware like HobbyKings ss2530 ESC)
Hardware.Implementations.Secretlabs (implementations for things specific to netduino board, things like Pins)
Quad.Net.FlightController (main entry point but in the form of interfaces, requires an implemntation, like fez or netduino)
Quad.Net.FlightController.Netduino (specific implementation of netduino board and its settings)

Example of Netduino Implemntation with a speedcontroller

using System.Threading;
using Quad.Net.ElectricSpeedController;
using Quad.Net.Framework.Implementations.SecretLabs.PulseWidthModulation;
using Quad.Net.Framework.PulseWidthModulation;
using Quad.Net.Hardware.ElectricSpeedController;
using Quad.Net.Hardware.Implementations.ElectricSpeedController.Implementations;
using Quad.Net.Hardware.Implementations.SecretLabs.Pin;
using Quad.Net.Hardware.Pin;
using SecretLabs.NETMF.Hardware.Netduino;

namespace Quad.Net.FlightController.Implementations.Netduino
{
    public class Program
    {
        public static void Main()
        {
            ICpuPin pin = new CpuPin(Pins.GPIO_PIN_D9);
            ISpeedControllerSettings electricSpeedControllerSettings = new HobbyKingSs2530Settings(pin);
            IPWM pwm = new SecretLabsPWM(pin);
            Controller controller = new Controller(electricSpeedControllerSettings,pwm);

            for (int i = 0; i <= 100; i++)
            {
                controller.ElectricSpeedController.SetThrottle(i);
                Thread.Sleep(50);
            }
        }

    }
}

What i have tried to accomplish with this is a framework where any contributor can swap out hardware, gyros or microcontroller that supports netmf and specific implementations of framework, fez vs secretlabs

What i'm hoping will happen is a user can throw a new esc in, implement an ESC interface specific to that esc, and fly 5 minutes later, or a board or a gyro or eventually other sensors, if we keep this generic enough we could add features and hardware very quickly and segregate the project in a more agile framework than what is being done in other projects as well as allow for various combinations of hardware software with little or no effort. Everyone else code that i have veiwed ha been scary dependent on hardware or assumptions and thus why the project falls down

well after checking out the feziQuad i took all their code and implemented it in my framework, main control loop, PID, obviously not testing with hardware and have no test coverage yet but its fairly slick if i do say so myself, it has his implementation of PID minus the windup, want to understand its implications first, i have not implemented his gyro, esc, or radio yet either. If we got in touch with Cummings, we could test this

If i get hardware and some skills with soddering i could be up and running right now, I cleaned up alot of his code as well

Magoocas, its in source control

Here's an entry point to give u an idea

using Quad.Net.Commons.Configuration;
using Quad.Net.ElectricSpeedController;
using Quad.Net.Framework.Implementations.SecretLabs.PulseWidthModulation;
using Quad.Net.Framework.PulseWidthModulation;
using Quad.Net.Hardware.ElectricSpeedController;
using Quad.Net.Hardware.Gyro;
using Quad.Net.Hardware.Implementations.ElectricSpeedController.Implementations;
using Quad.Net.Hardware.Implementations.Gyro;
using Quad.Net.Hardware.Implementations.Radio;
using Quad.Net.Hardware.Implementations.SecretLabs.Pin;
using Quad.Net.Hardware.Pin;
using Quad.Net.Hardware.Radio;
using SecretLabs.NETMF.Hardware.Netduino;

namespace Quad.Net.FlightController.Implementations.Netduino
{
    public class Program
    {
        public static void Main()
        {
            IConfiguration settings = GetStaticSettings();

            //Assumes one type of speed controller on quad
            ISpeedControllerSettings speedControllerSettings = new HobbyKingSs2530Settings();
            
            ICpuPin pinFrontESC = new CpuPin(Pins.GPIO_PIN_D9);
            IPWM pwmFront = new SecretLabsPWM(pinFrontESC);
            SpeedController electricSpeedControllerFront = new SpeedController(speedControllerSettings, pwmFront);

            ICpuPin pinRearESC = new CpuPin(Pins.GPIO_PIN_D8);
            IPWM pwmRear = new SecretLabsPWM(pinRearESC);
            SpeedController electricSpeedControllerRear = new SpeedController(speedControllerSettings, pwmRear);

            ICpuPin pinRightESC = new CpuPin(Pins.GPIO_PIN_D7);
            IPWM pwmRight = new SecretLabsPWM(pinRightESC);
            SpeedController electricSpeedControllerRight = new SpeedController(speedControllerSettings, pwmRight);

            ICpuPin pinLeftESC = new CpuPin(Pins.GPIO_PIN_D6);
            IPWM pwmLeft = new SecretLabsPWM(pinLeftESC);
            SpeedController electricSpeedControllerLeft = new SpeedController(speedControllerSettings, pwmLeft);


            Motors motors= new Motors(electricSpeedControllerFront,electricSpeedControllerRear,electricSpeedControllerRight,electricSpeedControllerLeft);
           

            AxesController axesController = new AxesController(settings);
            IGyro gyro = new DefaultGyro();
            IRadio radio = new DefaultRadio();
            ControllerLoopSettings loopSettings = new ControllerLoopSettings(settings);
            Controller controller = new Controller(motors, axesController, gyro, radio, loopSettings);
                      

        }

        private static IConfiguration GetStaticSettings()
        {
            InMemoryConfiguration config = new InMemoryConfiguration();
            config["PitchDerivativeGain"] = "-.5";
            config["PitchItegralGain"] = "0";
            config["PitchProportionalGain"] = "1.2";

            config["RollDerivativeGain"] = "-.5";
            config["RollItegralGain"] = "0";
            config["RollProportionalGain"] = "1.2";

            config["YawDerivativeGain"] = "0";
            config["YawItegralGain"] = "0";
            config["YawProportionalGain"] = "3";

            config["RadioLoopFrequency"] = "25";
            config["SensorLoopFrequency"] = "300";
            config["MotorLoopFrequency"] = "300";
            config["LoopUnit"] = "2";

            return config;

        }
    }
}

Magoocas, I didnt realize that video was you!!!! With a little bit of work you could fly with the code i've updated and a little bit of messing around with the source. I would love to see it run!

Yes i pm'ed you the credentials, let me give you your own Harness for your implementation will call it Quad.Net.FeziQuad.Implementation, dont think it'll fly right off bat there's a few things that might still need to be done, you've used some fairly specific esc implemntations and mine use some assumptions that i dont know yet, but not much will PM once i've committed with changes. Chris at this point i'm not sure the hz range i've seen has varied between 250 and 1000 level i've seen is, once i get some hardware in i can be more specific, I'll defer to Chris and Luke on this one

I have updated and made a very quick implementation of the hardware you have, there may be a few bugs in there but not bad for 10 mins work, your startup project is Quad.Net.FlightController.Implementations.FeziQuad

basically you read from one 3 axis gyro or 3 one axis gyro and from a 4 channel reciever and four escs which will be controlled via PWM

below is the simple data used by the reciever and gyro(s)

namespace Quad.Net.Avionics
{
    public class AircraftPrincipalAxes
    {
        /// <summary>
        /// http://en.wikipedia.org/wiki/Aircraft_principal_axes
        /// </summary>
        private int _pitchAngle;
        private int _rollAngle;
        private int _yawAngle;

        public AircraftPrincipalAxes(int pitchAngle, int rollAngle, int yawAngle)
        {
            _pitchAngle = pitchAngle;
            _rollAngle = rollAngle;
            _yawAngle = yawAngle;
        }

        public int PitchAngle
        {
            get { return _pitchAngle; }
        }

        public int RollAngle
        {
            get { return _rollAngle; }
        }

        public int YawAngle
        {
            get { return _yawAngle; }
        }

    }
}

using Quad.Net.Avionics;

namespace Quad.Net.Hardware.Radio
{
    public interface IRadio
    {
        int Throttle { get; }
        AircraftPrincipalAxes GetAxes();
    }
}

using Quad.Net.Avionics;

namespace Quad.Net.Hardware.Gyro
{
    public interface IGyro
    {
        AircraftPrincipalAxes GetReading();
    }
}

these classes would be tied to the events coming off those 6 or 8(gyro implementation specific) pieces of hardware and updating their values within the control loop

you beat me to it Chris, thanks.

As chris said there are a bunch of IMU's that cacn calculate speed, angle acceleration, but the simnplest is to start with a 3 axis gyro and then the aim is to get more complicated later, eventually implementing 5-9 degrees of freedom

Yea when i implemented your code i realzied I did that in my implementation, it can be remedied with a quick change to the control loop by calling the old update method explicitly and an alter of the GetReading() method not to call the update. I did a very quick and dirty with your implementation just as show of the style, the returning new AircraftPrinciplaAxes(...) each time is not efficient and can be remedied quick, but i didnt go into specifics there. If you make the change to the update and the return objects of AircraftPrinciplaAxes being held in memory and updating constantly GC will be exacctly what it s was in your old implementation

https://code.google.com/p/quadnet/ First stab at it, dont mind the pun

source updated, gc issue resolved as well as redundant update calls, precision is fixed as well as PID using windup guard was not properly implemented, if you can implement radio u should be solid, its the exact same code now

Chris, as always your optimism is fantastic. Part of the reason for this project is that i want to understand the concepts, so for me, this is a bit of exploration on the way in which these work (not just the quad but boards and simple EE work). At the end of the day if it doesnt work, i can convert that code to native, but as it stands this is the easiest way for me to define the domain. I honestly appreciate your input and experience with three quads, if it fails, it fails, if it works, you owe me a beer and one of your tricopters for me to pull the guts out of and put my .net microcontroller in and experiment with a tri. I was really hoping to use your experience in this project but i can see it will just be naysaying, so I will continue without.

I also think there is a reason that the original thread is in the top 5 most viewed threads in netduino forum, other people want to see it too

Day 2 of hardware testing with new code (in total 2 weeks old) on NETMF, IT HOVERS! Video tomorrow!

youtube wasnt taking uploads and Luke went to bed, he says he has a stable hover take a look at source its a pretty simple control loop right now but it works