Quad.Net Quadrocopter for .NETMF
#21
Posted 24 January 2011 - 05:37 AM
#22
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
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
Posted 24 January 2011 - 05:55 AM
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
Posted 24 January 2011 - 06:13 AM
#26
Posted 24 January 2011 - 06:19 AM
#27
Posted 24 January 2011 - 06:25 AM
#28
Posted 24 January 2011 - 06:34 AM
#29
Posted 24 January 2011 - 07:14 AM
#30
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
Posted 24 January 2011 - 08:00 AM
- Mattster likes this
#32
Posted 24 January 2011 - 08:31 AM
#33
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
Posted 24 January 2011 - 11:47 AM
#35
Posted 24 January 2011 - 12:05 PM
Could Periodic Interval Timer (PIT) be used instead/too?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.
#36
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
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.
#38
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
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users