Spiked

That will get you going, but down the road keep in mind there is a reason logic voltage and motor voltage are usually kept apart. There are several ways to accomplish isolation, one the easiest/best being 2 different batteries.

The problem is, in some configurations the motor pull can drop the voltage below what the logic can tolerate, even if just for a microsecond the results can be bad. Also motors, being mechanically/electrically connected (brushes sparking) tend to introduce 'noise' on the circuit and cause all  kinds of hard to find problems.

Again, hook it up as you described, see if it works, then think a more permanent solution.

Lock requires any object as a reference only. So you can use any reference variable that both places that need to lock have access to.  It is often easy just to create something for this purpose then in both place surround your code with; lock(lockObject) { ... }

Make sure you do it at a logical place, like before a transaction starts, but not too early or for too long.

namespace junk
{
    public class Program
    {
        static Object lockObject = new Object();
        public static void Main()
        {
            new Thread(thread1).Start();
            new Thread(thread1).Start();
            new Thread(thread1).Start();
        }

        static void thread1()
        {
            lock (lockObject)
            {
                // ... do stuff
            }
        }
    }
}

yeah, linux is taking over the desktop too, haven't you heard?

Lousy toolchain? What is your criteria? That it must look archaic? That must be it if you are thinking uecide is in the ballpark.

Sure there are a lot more imbedded level code samples/examples for the Arduino. It has a large community with that as the focus. The Netduino community is rather small and young so far. But there is no comparison between the languages Wiring (C++ like) and C# or even VB.Net. .Net is decades ahead of Wiring language wise.

An then are NO high level functions provided by an Arduino.  The code you write is all that is running, tiny, simple and mostly fast.

.Net provides much greater functionality. No need to use pointers (yes, they are a bad thing), Actual remote debugging, (not printf to a serial port), collections similar to STL (which I have never seen on an Arduino), actual documentation (up to date and not some stale automatically generated help files) .... and many more I can't think of at the moment.  These are provided at a cost of speed, but they are usually are written in a manner that is far more efficient than anything you are going to write that does the same thing.

And now let's talk IDE.  The absolute worst case is Visual Studio may not be the best anymore, only tied as the best (Eclipse). And in a .Net environment, you can not even say that, since Eclipse does not do .Net debugging. Refactoring built in (change a variable name one place, the IDE takes care of it everywhere, automatically)  Find definitions and references to variables, not some limited text search and replace, that does not consider the language syntax. Project management without the need to manually edit and manipulate build/make files, although that is an option if desired. And my favorite, it does not look like it was written by dinosaurs in COBOL.  Having a professionally thought out IDE is especially important when you spend 8+ hours a day writing code. Visual Studio has been maturing for 25+ years, from a company that knows a little about how people use computers (like it or not, still 87% market share, down from 95%). 

Putting a Netduino into production and calling wall warts cheap china crap is pretty much an as far from a success story as you can get. Good luck. Where do you think all the parts on your Netduino are made?

You had my curiosity peaked so I tried your program (on 4.3.1).

It ran as expected .... but

I will say it acted weird(er) than other programs. I don't know if you triggered some bug with a variable name or what, but there is a big delay when it starts (4-5 seconds).

I have 2 N2+ now, and they work differently as far as debugging, how many times they reboot when starting. The newest one consistently usb disconnects 3 times, then starts loading symbol tables. The previous one was a random number how many disconnects/reconnects it goes through.  The moral is I doubt if there is consistency among units at the moment.

I'll contrast this with the Galileo which feels rock solid as far as debugging (which also uses the ethernet connection not USB). 

https://webchat.free...indowsondevices

Just an update; indeed the robot did acquire a LIDAR.  It is the Robo Peak LIDAR as was intended.

I think the device is good so far, although you can find hack'd neato version on eBay now for < $100. I'm not sure how good the drivers are for them.

The drivers that came with the RP weren't the highest quality either.  C++ only and everyone seems to just copy the original code because no one can understand it.  The data sent from the device doesn't match the documentation exactly, but it's close.

sidenote: the right hand sonar is not mounted because it is broken. This is what happens when you say 'go forth' and don't have working collision code :|  

.Net  is an interpreted Managed language.

As such there are a few things you should not do if you want efficient code.

Note that efficiency was not a goal of .Net, robustness was. That doesn't mean you can not be efficient, you just can not go throwing around features that were intended to protect you from yourself, and expect efficiency.

In your main loop, you re-allocate (using) a i2c device 3 times every loop. That has to be cleaned up by the garbage collector. Allocate it once outside the loop, then re-use it.

Same can be said for your transactions.  There is NO reason to re-create 9 (or worse as I looked more, you are doing bytes?) of them every single loop.  Creating new objects is not free, nor is disposing of them when no longer being used (every loop in this case).

I posted an article a while back when I first started playing with the Netduino, showing an efficient way to talk to an i2c IMU; http://www.spiked3.com/?p=421

The code in the next post show multiple devices, so look at it also; http://www.spiked3.com/?p=438

Bottom line;  Think every time you use 'new', and if it is appropriate. Do not just copy someone else's code without understanding it.

I did not intend to imply people were parked in handicap spots, just the opposite. Seattle is a very handicap unfriendly city. Most of the people are (on average) young wealthy health nuts so not much attention is given to/for handicap. Thus there is NO handicap designated parking. 

The more I think about it, the more I think I probably would not be a good candidate for one of these boards anyhow. I don't get it. I have yet to understand ANY reason for it to exist, and especially no reason to take attention away from other existing platforms. It really looks like another Ms throw money at the wall, and see if anything sticks, and I can tell you the outcome.

The chat today on IRC was that indeed Ms is 'selecting' who they will be sending kits to, based on intent.

Way excited - this is cool stuff I've never seen done with a netduino

Yes. I am actually pretty advanced in the FPV quad hobby.  

The quad in the picture has a 5.8g video transmitter. The one in the video has a 1.3g video transmitter that goes to a 1.3 receiver, that retransmits to 5.8 - so I can wear the same wireless 5.8 fat sharks for both.  1.3 has better foliage penetration, but 5.8 has more frequencies channel choices - so it depends on if you are flying with friends or behind trees.

my meetup group

http://www.meetup.com/wa-fpv/

That is the best US source I know of for the board. They just sell fast (for obvious reasons). Keep checking.

SPARKFUN 9DOF IMU STICK ACCELEROMETER AND GYRO RAW DATA TO WPF VIA MQTT

So, still learning, but I seem to be getting along ok, solving a few problems I see others encountering - so if the code helps anyone, great.

If nothing else it shows off WPF simplicity a little for those of you unfamiliar with with it. WPF was the intended replacement for UI on windows.  It has been made 'legacy' at this point, but the follow-up - WIndows Store apps are very similar.

http://www.spiked3.com/?p=438

direct links;

http://www.spiked3.c...2014/06/imu.zip

The video shows some 'unaligned' response. I assure you this was a video alignment problem. In actuality the response is very fast and aligned.  Next time I will do the screen capture differently as I think frame rate differences messed with me.