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

NetDuino Quadrocopter


  • Please log in to reply
75 replies to this topic

#1 Brandon G

Brandon G

    Advanced Member

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

Posted 02 January 2011 - 09:32 PM

I am looking at porting the kk multicopter code to C# and wondering if there are any others that would like to get involved in doing a quadrocopter project in C#?

#2 renatoa

renatoa

    Advanced Member

  • Members
  • PipPipPip
  • 36 posts
  • LocationRomania

Posted 03 January 2011 - 07:39 AM

Could be, but isn't already out the wiicopter, using Arduino mini ?

#3 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 07 January 2011 - 07:20 PM

NETMF and quadcopters flight critical code don't mix.... At all.. You really want to have a native flight stab computer and maybe a Netduino attached to it. As it is, I have a quadcopter project started, it will be a custom board design and will use either an FPGA or a Parallax Prop as the flight stabilization computer. The FSC will be tied to a NETMF board for control input.

#4 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 07 January 2011 - 08:24 PM

This would probably require some timer/interrupt-driven C++ code in the background that runs underneath .NET MF. Such code could be compiled into the open-source Netduino firmware. As Chris Seto mentioned, an external chip makes things really easy...use the Netduino as the "logic controller" and the external chip as the real-time executor. Chris

#5 Brandon G

Brandon G

    Advanced Member

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

Posted 12 January 2011 - 05:19 AM

Hey Guys, sorry for the late reply, been out of country. Chris S, being new to netduino i will definitely capitulate to your assertion that it is hard if not impossible but would like to understand your reasoning, is it GC or the interrupt events not firing fast enough. If the latter would Chris W's suggestion handle that issue? I would rather not mix and match and cause more latency in decision making and context switching between languages and boards if possible. The reason i picked KK's project was that it started simpler than any i had seen, only uses 3 gyros, no accelerometer, magnetometer or gps out the box and fly's more stable than anything i have seen yet. As i look at the math of this thing it looks like a rather simple C# project (although i don't know how limited the math libraries are in the MF). Regardless this is the plan. I'm going to start with a simple KK build, which is proven and simple, use their board. Then i am going to start building my own board with the same simple 3 gyro system with netduino and do simulations without flying and continually add components. If gc is the issue i think we can get around it by promotion to first class citizens and ugly use of pinned objects and always having them in memory, my previous projects were in real-time stock market analysis, handling 20millions messages/second, stabilization should be simple comparatively. if the latter nd me being new to .netMF and netduino i would hope that the event firing systems of this board were not inferior to what is out there now. let me know your thoughts. also Chris W from a marketability standpoint a project like this could help give this hardware a nice showcase. Brandon

#6 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 12 January 2011 - 06:55 AM

Brandon, it's a horrifically bad idea to run anything time critical in NETMF. Although NETMF can be *fairly* realtime, you can still end up with issues with the GC popping in, and besides that, managed code will run much slower than native. A quadcopter needs as fast of an update rate as it can possibly get. 500Hz is within the realm of what's acceptable. That includes the setpoint reading, the PID correction, and the PWM manipulation, as well as anything else that needs to be done. There is no complex math in a simple quadcopter. It is basic calculus that can be done with simple multiplication, division and adding, all of which NETMF will support without issue. What NETMF will not support is running a high performance control loop, which is required on a inherently unstable aircraft like a quadcopter. This is one of the reasons why the FPGA is such an attractive target for a quadcopter. It can run the control loop faster than the ESCs, motors and props can even begin to respond.

#7 Brandon G

Brandon G

    Advanced Member

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

Posted 12 January 2011 - 07:30 AM

Chris, with all due respect these are the same arguments i have had in past with the *Kings of quant on wall street and managed to make consideration for GC and when we handle objects correctly we can make anything perform as well if not better than native depending on the skill level of programmer. You make bad objects that require a GC pass constantly you will have issues. Now i do understand that GC is an issue but if your argument is simply GC I think i can proceed just with a more clever use of memory and objects. Now if there are inherent issues with the board and firing of events then we have an entirely different issue.When i work in finance we are making adjustments far faster than anything required in a quad stab engine so for me thats a non issue within the framework, my concern would be the board itself if thats it

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 12 January 2011 - 07:36 AM

If there are native code routines that need to run at specific fast intervals, that can be accomplished using the MCU's timers. If we put together a good set of requirements, perhaps we could create some native code that could be invoked dynamically (using Corey's fluent programming model or a firmware extension). This is not trivial to create, but it would preempt both managed code and garbage collection...and would be easy to invoke once created. Calling code every 2ms that performs calculations is well within the Atmel MCU's capabilities. That said, using an external chip makes this problem even easier to solve... Chris

#9 Brandon G

Brandon G

    Advanced Member

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

Posted 12 January 2011 - 06:15 PM

http://www.kkmultico...loads&Itemid=65 take a look at the source, as i am new to the hardware side it has a few board properties i dont quite get, but the main logic is on the ISR and the loop. They also have asm code but i figuire this a little easier to read.

#10 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 12 January 2011 - 09:04 PM

Brandon, I can assure I have done extensive testing on control theory within NETMF, and the conclusions that are represented above are as a result of those experiments. I'm sure you can make rapid adjustments to data in your financial application.... when you are running on a fully fledged x86/x64 target with gobs of resources. NETMF targets typically do not have *gobs* of resources, and therefore a valid comparison cannot be made. As far as creating a firmware extension based off a reference set of requirements, I suggest these: Capable of * Setpoint acquisition (IE, reading the PPM position from the RX for each of the 4+ channels (probably from a PPM decoder IC) * PID correction delta -> absolute generation * PWM PPM waveform assignment for each of the 4 ESCs. ...all within enough time to hold a ~500hz control loop, which is roughly equivalent to a typical native target.

#11 Brandon G

Brandon G

    Advanced Member

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

Posted 12 January 2011 - 10:18 PM

Maybe i am being a bit naive here then. I was really hoping for an easy board to work with and this might not be the case then. I was hoping to do all this within the managed framework, PID, PWM PPM, RX fired from the events of the components attached to the board, similar to the ISR event of other boards (Once again i am a noob when it comes to the way in which these components interact back with the program) if the events fire fast enough we can make up for any small delays with a different PID calc. So as data comes in from gyros, reciever, escs they will fire events and we can interact with those instantiated objects that provide the stability}, I was planning on instantiating all objects at startup and using a CQRS style of messaging objects from the events with a time sensitive queue LIFO, this way when GC does come through its fast as all hell and is disposing small objects and not interrupting the main objects. the reason for the messaging objects is we can then take that data and lazy write it to an sd card for running simulations and debugging a flight afterwards, makes for a great picture of events and replayablity. 500hz seems a lil high to me and maybe overkill, Ive heard of people flying quite sucessfully with a loop operating in the range of 40 to 50hz and then going up to 500 and even 1000 and seeing no obvious gains, but until i start testing I wont know. I would hope we could achieve 40hz without changing or extending the firmware, btw i like the fluent model by corey seems interesting and would like to see his progress. To be honest i probably wont be using the RX at all within this project, plan on using wifi and tethered testing to start. So just make it fly stable account for wind and hover is part 1.

#12 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 12 January 2011 - 11:49 PM

Yeah, no way this will work all managed. I have done PPM decoding in managed code and it was very ugly. That was just 2 channels, too, not counting all the other stuff that needs to be handled. Besides that, I see numerous problems with the proposed architecture, NETMF simply doesn't work as fast as you think it does, and 40hz is not going to produce a very stable quad. .NET is _really_ not meant to run time critical things like quadcopters. I can guarantee that you will never find an autopilot in any application running on NETMF, unless it's something like on my RC car project where there's a ton of slop anyway. Also, not using an RC TX is another fatal error. Last time someone tried that, they ended up with a quadcopter that climbed to 90' and stayed there until eventually the batteries died and it fell back down. You really need something to sanity test, and I can assure you that you will not be able to create a suitable autostab having no time handflying the aircraft with a real RC transmitter. If cost is an issue, you can get a Hobbyking 4channel TX for like $20, however I would be weary of trusting a very expensive quadcopter to a cheap TX. :) Sorry if it seems like I am being a professional wet blanket, it's just that I'd like to make sure you are aware of the limitations of such ambitions.

#13 AlfredBr

AlfredBr

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationConnecticut, USA

Posted 13 January 2011 - 12:09 AM

I'm not trying to start a flame war, and I imagine what you are saying is quite true in specific circumstances. However, I am not convinced that broad statements like ".NET is _really_ not meant to run time critical things" are generally accurate.

#14 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 13 January 2011 - 12:17 AM

I'm not trying to start a flame war, and I imagine what you are saying is quite true in specific circumstances. However, I am not convinced that broad statements like ".NET is _really_ not meant to run time critical things" are generally accurate.


Yeah, sorry if my responses sounded like I am trying to start a flame war, I am not... :)

But, ask any highly experienced .NET programmer what they think of running a helicopter autopilot on .NET and you'll get your answer.

.NET is not designed to run highly time critical applications, it's designed to provide an extremely high level development environment. If you want to make an autopilot, you run it on appropriate hardware.

#15 AlfredBr

AlfredBr

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationConnecticut, USA

Posted 13 January 2011 - 12:40 AM

Do you mean .NET in general or NETMF on the Netduino specifically? Or something else entirely? What specifically about .NET makes it unsuitable for highly time critical applications?

#16 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 13 January 2011 - 12:54 AM

I am talking about NET entirely, including MF and CF. .NET is designed to be a high level software development system that makes it very easy for applications to be rapidly developed and debugged. Typically, these applications don't care much about time. Who cares if it takes 20 seconds for a user to push a button? .NET was never designed to be able to execute a loop as rapidly as possible, in a highly consistent manner. I have a project on my desk right now that makes use of hardly any events (just one for a timer) and there is still a noticeable lag sometimes when the GC runs and the servo stops mid travel, then continues along. You are talking about wanting to make _heavy_ use of events without getting the GC involved, that just isn't going to happen. You are also talking about using the filesystem which is a big unknown. That can delay things as well.

#17 Mark H

Mark H

    Advanced Member

  • Members
  • PipPipPip
  • 70 posts
  • LocationPerth, Western Australia

Posted 13 January 2011 - 02:23 AM

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.
  • Brandon G likes this

#18 Brandon G

Brandon G

    Advanced Member

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

Posted 13 January 2011 - 05:21 PM

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. Granted GC is an issue, i am not claiming i am going to have 400 passengers on my quad but conversely i will guarantee any code i write will not fly to 90' until it runs out of batteries. 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. Back to quad, for me this is a fun project to do something neat and cool to get my mind off the constant shite of work, hopefully i can find a community that wants to embark on it as i do with my limited hardware skill or i will try and do so on my own, the former favourable, i would hope this community would want to do more with its framework than what i have seen in the showcases, .NET is a great language and has huge potential in this space if WE can make it better, managed code has a bad rap because of bad programmers the easy barrier to entry, those at the forefront can make it a feasible and quick alternative for practical applications if we work around/with the inherent disadvantages / advantages. In closing i will say that for me this netduino project is an opportunity to step out of just programming and see material physical results of my effort, which is a huge, I have always wanted to bridge the gap between the real world and the virtual and thats what i love most about this project. anyway brandon
  • Michel Trahan likes this

#19 AlfredBr

AlfredBr

    Advanced Member

  • Members
  • PipPipPip
  • 138 posts
  • LocationConnecticut, USA

Posted 13 January 2011 - 06:32 PM

... it's totally random, unpredictable, and uncontrollable - this is the issue.


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?

#20 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 13 January 2011 - 07:06 PM

Hi Brandon, I for one would love to see a quadcopter project. We could start with fully managed code (written in a state machine architecture with objects declared up front so that we minimize garbage collection costs). Then if there are calculations or routines which need to be done faster (or on a microsecond-resolution timer) we can investigate creating native code plug-ins to accomplish those activities. We're doing some crazy stuff with .NET Micro Framework at Secret Labs on commercial products where microsecond timing is necessary (mixing native and managed code)... A quadcopter is well within reason, but it'll probably require a bit of interop. Anyway, I like pushing the boundaries and I think it would be fun to watch you on your journey (and pitch in if we can spare a few dev cycles). Chris
  • Michel Trahan likes this




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.