n regards to the deterministic comments, gc is a mofo and can kill you at the worst times. what i think will compensate is the PID algos and making them smartand aware of the state of system. If there were on thing i wish would be built into .NET would be more ability to talk to GC and get stats and state of it. I have messed with GC a few times with very little success. It would be great to know where it is at in operation, so i could query it and understand that i should in this case, try and level out my quad or purge my queue because i know it to be too late etc

corey, i will prolly try and start a little heavier than that and optimize as i go and if the quad requires it, not being silly mind you but will try to make it elegant to start and get tighter in high traffic areas.

Chris W, thanks, as i said i hopefully wont have to break the microsecond barrier in any way from the outset, if so i will prolly throw my quad against the wall in frustration, as for the release i understand and will try not to be a burden i know you guys are busy and need o focus on your core business

I agree GC is always going to be an issue and that i am not running on a xeon processor, but if i can keep things simple and be cognizant of the types i use i think i can do this pretty simply without gc killing me. Have many people linked netduino's together to get more punch or isolate processes, there is a possibility i could chain them and use individual boards for individual operations with incredibly simple operations back to a duino that is the master controller. This is partially why i have decided upon the kk code, seriously, take a look, its scary simple and low throughput. if i get more complex i could distribute the processing a bit. Mark, Chris, in no way did i mean to question your abilities as programmers, my college drag and drop comments were against the attacks of the .net framework as a whole, not the netmf running on lil processors. I've done some walkthroughs on code on some of the netmf sites to get an idea of the hardware integration side and the code makes me shudder. Take my most humblest of apologies if i offended, was not my intent and i plan to be on this site for quite some time and learn from everyones experiences in order to get better on the hardware side. thanks again for all your input and i will post back as i go.

greg and i worked together for 5 years that initial implementation was ours, albeit naive it suited our purposes. They are all teeny, almost any well written serialization implementations will be, i'd love to help out.

i think if we just did value types and collections of value types with recursion of more complex obecjts as long as they were all inheriting the same interface to start we could open it up from there, i'm new here and wondering if you guys have a svn or git repository going yet? if not I could host something up on mine if need be. Hopefully if i can help on the code side you guys can scratch my back a bit on the hardware side

thanks chris, i'll look at swapping them out. Yea im trying to start with the cheap basics and move my way up from there as i get more familiar (crash less) hopefully i can get it off the ground. The gyros/esc's ive mentioned, do you think i'll have any issues communicating with them on netduino

Chris are the interfaces there to be implemented? IFormatter etc http://codebetter.co...-serialization/ old but still works

building a lightweight serializer wouldnt be too hard, I have some old source that could work, its optimistic and only handles simple objects. I will more than likely be re-visiting it soon in my quad project. What are you wanting to serialize (what types of objects)?

also i should mention that i did get this build list from warthox, http://warthox.bplaced.net/?page_id=76 , whom has some of the craziest quad and tri copter videos i have seen yet on the web, which is what started me wanting to do this so badly

Thanks for your reply Chris, That's the exact architecture i was thinking. A state machine that instantiated all the main objects at startup and then using a messaging pipeline with handlers for interacting with the state machine cqrs style, will make for easily debuggable code as well as rapid development and future feature building, ie gps, accelerometer, sonar, magnetometer, video, wifi, cellular communication, autonomous functions, load carrying etc. The initial setup is as follows motor: emax fc2822 1200kv esc: hobbyking ss 25/30 props: epp 8×4.5 cw/ccw sbec: hk turnigy 5A frame: quadframe.com battery: turnigy 3s3000 20C controller: kkmulticontroller 5.5 once up and running i will start with the netduino board and add: 3 HobbyCity HK401B gyros and try to get those to work with the netduino Will be ordering components soon and will keep you all appraised of my progress.

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

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.

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.

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

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

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#?