75 replies to this topic

[Brandon G]

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.

[Brandon G]

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

[Chris Seto]

I'm not saying that I don't want to see a quadcopter project, because remember that I actually do own a quadcopter that isn't more than a stones throw away from it's first flight, I was simply suggesting that you find an alternative target for the FSC. I have seen plenty of NETMF quads; none of them have ever flown. That said, you probably want to use a different source of power for the FCU, BECs (erm, well, basically everything in the RC world) are usually horribly noisy and not the kind of thing you want to power your computer on. Look at an el-cheapo 2S lipo from hobbyking.

[Brandon G]

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 Walker]

Very cool, Brandon. I think that the learning experiences of the journey are half the fun. Just remember that you might need to hack away at the C++ firmware a bit if you do end up needing microsecond-accurate timings that aren't provided by PWM. We'll make recommendations along the trip, and it may make sense for us to write some native code for inclusion in the general firmware, but just to warn you in advance our priority right now is on the v4.1.1/4.1.2 releases... I can't wait to see your project come together... Chris

[Chris Seto]

Timing for PWM only needs to be capable of around 256 steps or so for that Turnigy ESC.

[Mark H]

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

I'm not starting a war here either, neither is Chris, we're simply trying to inform you of the limitations of an interpreted language running on a 48mhz processor. We're not saying it can't be done - you just seem to think you're going to get the same pure C# performance out of a tiny little SoC device that you're used to at work/in full .net.





The financial application you are running I'm guessing is on a dedicated server with multiple quad or hex core xeons running in the 2.2-3.2GHz region, with tens of gigabytes of ram. This is a 48mhz, single chip with 60kb of ram. Full .NET runs JIT, NetMF is fully interpreted.

During the day I work on mine scheduling software. This uses complex genetic algorithms and we run our service on a bunch of 24 core Xeon blades (4x hex core) with 8gb of ram per core. With the size of the data we are processing (1-2 million blocks with all the genetic crossovers, village, population data etc), optimisations that take 10 microseconds off code execution time can save minutes. I do a lot of optimisation work and have been working with the CLR since the beginning on the full framework, as well as CE and asp.net.

NetMF is a whole different beast. I've also worked heavily with the NetMF CLR, I have a large library of methods in C# that are faster than their native CLR equivalents, sometimes 3-5x faster. I'm not a college tweenie or amateur developer, I'm employed as a software engineer and have been for the past 8 or 9 years - only working with C# in the office. I say this not to brag, but to try to give what I'm saying some weight. I know the CLR inside out, I have no issue with writing MSIL, I've published articles on C#, I know how to optimise C#. In my own time, i write C#, C and C++ on embedded systems.

A 48MHz ARM running IL natively would be fine, a 48MHZ arm running JIT would be OK, a 48MHZ ARM running C++ code that interprets IL is slow. Each IL call takes dozens, or hundreds, if not thousands of instructions (depending on what it is) to execute. You don't have the pipelining or co-processing that a Xeon or other intel/AMD chips have.

I'm not a hardware person who's learnt software, I'm a software guy who over the past 4 years has learnt a lot about hardware through trial and error.

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?

C# events, threading and the garbage collector (among other things) can interrupt the execution flow of your code, causing this unpredictability. Sample code? Create an application, run it - there you go. I can guarantee that you will not see the exact number of clock ticks pass for every single loop of code unless it is an ultra simple app like blinking LED's. The simple fact is, this is a managed language - you don't have total control over what happens when and how.

[AlfredBr]

The simple fact is, this is a managed language - you don't have total control over what happens when and how.

Shouldn't it be deterministic? Given that it is just our code/firmware running on a closed system, why wouldn't every loop iteration be deterministic?

(I am reminded that we landed on the Moon with less memory and processing power than is contained on a Netduino.)

[Chris Walker]

Shouldn't it be deterministic? Given that it is just our code/firmware running on a closed system, why wouldn't every loop iteration be deterministic?

(I am reminded that we landed on the Moon with less memory and processing power than is contained on a Netduino.)

If you're not using events or timers and are not creating objects which require garbage collection, .NET MF can be near-deterministic. Interrupts will still fire to queue up incoming data (on I2C/SPI/UART buses for instance) and the scheduler will still interrupt the current thread every 20ms to make sure nothing else is waiting, but generally things will run pretty smoothly.

Windows CE recently got "native real time" support. We could help do the same thing for .NET MF if there was enough demand for it, but it would probably need to happen in the core. In the meantime we can certainly create interrupt-driven features with "near-real time requirements" although that's not nearly as easy as writing managed code.

Chris

[Corey Kosak]

Given that it is just our code/firmware running on a closed system, why wouldn't every loop iteration be deterministic?

I would interpret this as saying that every loop iteration is going to be variable but more-or-less deterministic until your quadcopter takes its first reading from the outside world, and at that point you'll lose the determinism.

(I am reminded that we landed on the Moon with less memory and processing power than is contained on a Netduino.)

And Columbus made it to the New World with even less!

Just as a micro-point on the topic of reducing GC, I kinda like the style of programming where all your objects are structs, and you pass around refs everywhere (being sure to pass "ref x" rather than "x" in order to avoid making a copy). This will hardly solve all of your problems, but might be a nice tip to keep in mind.

[Brandon G]

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.

[Brandon G]

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

[Brandon G]

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.

[Brandon G]

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

[Brandon G]

and i always love the moon reference, its bloody amazing they did it at all. its funny but a quad is harder and requires more calcs

[Mark H]

I too find the moon missions just incredible, the amount of work that went into hand winding memory alone is insane. You have to remember though, that was hardware designed to work with software for one specific purpose. There was no managed code haha. It also had the best hardware and software people in the world working it. Consider the Apollo computer to be similar to custom silicon, such as in a graphics card or digital slr. You wouldn't expect a micro processor to be able to do that even if it has higher specs, or if it can do it - it wouldn't do it well.

I agree, some code out there is absolutely hideous - but everyone learns somewhere. I'd hate to look at my first attempts at coding (which i probably thought were brilliant).

As far as you go optimising, i'd suggest you start with making the code as easy to work with as possible, then look for the slowest sections of code. There is no profiling on NETMF so it's pretty much a matter of knowing where it is going to be slow, making a test harness and then executing that code 1000 times, make a change, execute another 100 times, see if there was a speed improvement, rinse and repeat.

Rather than going multiple netduino's to handle the task (this is basically the mythical man month) go with a real time processor - you could use something high level such as a Propeller or low level such as a dsPIC. This would handle the PID loop (or whatever pattern you use) and take input from the netmf chip. NetMF would be handling navigation, position, etc.

[Jan Olof]

Hi I took a look at the gyros you proposed HK401B, I am nu RC or gyro expert but to me they did not look promising to interface with the Netduino. What I could see is that they was black boxes that you put in between your RC receiver and your servo, with no other data output you can use. Also what I understood so are they specialized to keep your heading and interfaced with rudder. But I might be very wrong here. Anyway take a look at sparkfun and their sensors, and the Gyro and Accelerometer guide. /Jan Olof

[bill.french]

Is this evidence of the "issue" - or is it just a precision issue with the Saleae Logic Probe? Notice the highlighted gaps, which are regularly repeating.

I used this code:

namespace TightLoopTest1
{
    public class Program
    {
        public static void Main()
        {
            OutputPort d2 = new OutputPort(Pins.GPIO_PIN_D2, false);
            bool status = false;
            while (true)
            {
                status = !status;
                d2.Write(status);
            }


        }

    }
}

and got this @ 24Mhz:

[CW2]

Is this evidence of the "issue" - or is it just a precision issue with the Saleae Logic Probe?

I would guess this is caused by scheduler, it has to check what should be run next after 20 ms time quantum elapses.

[dones]

Hi all, This is very interesting- thanks for starting the thread Brandon! I too have been working with .NET since it first came out, and have been fascinated by the possibilities with the micro framework ever since someone sent me a link to the FEZ site last summer. The discussion here reminds me of the comparisons we used to make between Visual Basic and Visual C++ back in the pre-.NET days. With VB, it was very easy to throw together user interfaces and such, and and it was definitely a useful product for certain types of projects; however, for timing critical, multi-threaded apps, Visual C++ was the tool of choice. I think someone once said something to the effect of: "VB can do 90% of what VC++ can do, and be developed in half the time. But the other 10%, VB can't do at all". When .NET was released, it seemed like a nice combination of the two platforms and a nice alternative to Java. That said, with all of the financial/automation apps I have written since .NET was released, it seems like SQL Server has always been the bottleneck, so native code really hasn't been an issue these days, but I digress... I've been "into" multi-copters for a while now and have built the original (hand wired) KK controller, an MK, and UAVX. I really think a .NET quad would be awesome, but the more I read about these things, the more skeptical I am about .NETMF being able to support complex timing needed with PID code and all of the inputs and such. Of course I am very new to this, so my opinion carries very little weight I would offer this suggestion though: start simple with a "proof of concept". Instead of building a full-blown quad with 3 gyros, start out with 2 motors on one axis with one gyro. Basically, just have two motors mounted on a single arm, with the arm "hinged"/tied to something fixed in the middle to keep it from flying away. You'd be able to see how well the controller responds to inputs, and tune for oscillations, etc. here is a link to some .NET PID code if you're interested: http://www.fezzer.co...roller-example/ Good luck!