Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Quad.Net Quadrocopter for .NETMF


  • Please log in to reply
119 replies to this topic

#21 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 24 January 2011 - 05:37 AM

Chris: YGPM

#22 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2011 - 05:41 AM

Chris: YGPM


Thank you. Awesome.

So let's say ~500Hz...

That would give us a control loop which would execute "in the background" every 2ms.

I'm not too familiar with quad copters. What are the exact bits of data that need to be read/processed by that control routine? The critical code could be written in native C...with a wrapper class letting .NET MF send data to the native code and get events.

Maybe someone could make a quadcopter kit for Netduino :)

What are the bits of data that need to be read/written/processed by the control routine? Also, what would the methods into and events out of the native code be?

Chris

#23 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 24 January 2011 - 05:48 AM

Thank you. Awesome.

So let's say ~500Hz...

That would give us a control loop which would execute "in the background" every 2ms.

I'm not too familiar with quad copters. What are the exact bits of data that need to be read/processed by that control routine? The critical code could be written in native C...with a wrapper class letting .NET MF send data to the native code and get events.

Maybe someone could make a quadcopter kit for Netduino :)

What are the bits of data that need to be read/written/processed by the control routine? Also, what would the methods into and events out of the native code be?

Chris


Read:
PV: Yaw (gyro/compass composite)
PV: Pitch (gyro)
PV: Roll (gyro)
SP: Setpoints (from RC RX or autopilot)

Almost all PVs (not Yaw) can involve a accelerometer as well to detect the actual flight angle.

Each PV has it's own PID controller.

Write:
4x PPM

#24 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 05:55 AM

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

#25 Luke Cummings

Luke Cummings

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts
  • LocationCalgary, AB

Posted 24 January 2011 - 06:13 AM

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... :unsure:
Cheap, Fast, Good... Pick two

#26 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 06:19 AM

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

#27 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2011 - 06:25 AM

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

#28 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 06:34 AM

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

#29 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 07:14 AM

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

#30 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 24 January 2011 - 07:40 AM

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


+1 to this. Writing the control code in NETMF is only going to be met with failure. As of now, I have ~3 quadcopters (well, one tricopter-ish thing). Trust me, you do not want to see one have a failure midflight. The aircraft will instantly flip over with absolutely no way to recover. It's far worse than even a deep stall in a fixed wing aircraft. I know you want to write the code for this in a high level language and I can respect that interest, but this really isn't the right scenario for that.

#31 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 08:00 AM

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.

#32 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 24 January 2011 - 08:31 AM

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

#33 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 24 January 2011 - 08:35 AM

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


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 :)

#34 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2011 - 11:47 AM

Regarding FIQ: to set good expectations... FIQ is a wonderful thing: a single "highest priority" thread of execution which can execute every ## nanoseconds or when a specific event occurs (line active, character received, etc.). The good news is that it's powerful. The bad news is that of course there's just one of them. And while it can be turned into a priority-based FIQ handler (handling lots of time-sensitive tasks on a priority-ranked basis), that largely defeats the point of FIQ. So here are some ways that we'll be the FIQ feature: 1. Software PWM -- at least one channel, maybe more 2. Enhanced PWM for hardware/software PWM -- special waveforms, anyone? 3. High-priority native code interrupts (like quadcopter "loop" logic) But again, you can only have one at the same time. We can also expand the IRQ infrastructure (think of it like a less time-accurate version of FIQ that will occur but may be a few hundred nanoseconds late, for non-critical functions). Chris

#35 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 24 January 2011 - 12:05 PM

FIQ is a wonderful thing: a single "highest priority" thread of execution which can execute every ## nanoseconds or when a specific event occurs (line active, character received, etc.).

The good news is that it's powerful. The bad news is that of course there's just one of them. And while it can be turned into a priority-based FIQ handler (handling lots of time-sensitive tasks on a priority-ranked basis), that largely defeats the point of FIQ.

Could Periodic Interval Timer (PIT) be used instead/too?

#36 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 24 January 2011 - 01:05 PM

Could Periodic Interval Timer (PIT) be used instead/too?


The PIT is a system peripheral IRQ interrupt, so it's being called from the same priority-based IRQ handler that is managing UART character buffers, system timers, etc. It's priority 7/7 so it's high priority, but it can still be delayed up to 50ns or so at times.

That said, one of the timers can be "fast forced" to FIQ status. The ones you'll usually want to use are the 3 16-bit timer channels (at least one of which is reserved by .NET MF).

Chris

#37 Luke Cummings

Luke Cummings

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts
  • LocationCalgary, AB

Posted 24 January 2011 - 02:31 PM

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.
Cheap, Fast, Good... Pick two

#38 Jim Wells

Jim Wells

    New Member

  • Members
  • Pip
  • 8 posts
  • LocationOrlando FL

Posted 24 January 2011 - 02:52 PM

Chris,

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


We all understand limitations exist, but where would advancement be if we did not push the envelope. Keep on flying!

"I have not failed 1,000 times. I have successfully discovered 1,000 ways to NOT make a light bulb." – Thomas Edison

#39 Luke Cummings

Luke Cummings

    Advanced Member

  • Members
  • PipPipPip
  • 38 posts
  • LocationCalgary, AB

Posted 24 January 2011 - 03:02 PM

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.

Edited by Luke Cummings, 24 January 2011 - 03:04 PM.

Cheap, Fast, Good... Pick two

#40 Brandon G

Brandon G

    Advanced Member

  • Members
  • PipPipPip
  • 92 posts
  • LocationVancouver BC, Canada

Posted 25 January 2011 - 06:12 AM

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.