Back in Q1 of 2013 I posted a sample application which called an Azure Service Bus end point just to confirm that the certificate configuration etc. was good.
Since I published that sample the Azure Root certificate has been migrated so I have created a new project which uses the Baltimore Cyber Trust Root certificate.
The sample Azure ServiceBus client uses a wired LAN connection (original one used wifi module) and to run it locally you will have to update the Date information around line 24.
One of my co-workers is involved with a group that run “code clubs” at local schools teaching high school students how to code.
We got talking about projects which would appeal to the students and I suggested making a mobile phone. This is my prototype
It’s more Nokia 5110 than Nokia Lumia 820
If you want to build your own (the parts list will grow as I add GPS, accelerometer, compass, screen etc..)
For V0.1 of code one button sends and SMS to my mobile, the other button initiates a voice call to my mobile. The initial version of the code was based on the SeeedStudio GSM Shield Netduino driver on codeplex.
The later versions are based on the CodeFreakout Seeedstudio GPRS Shield drivers which are available via NuGet. I have added some functionality for dialling and hanging up voice calls which I will post for others to use once I have tested it some more.
So according to cuno and co NetMF is a viable processing platform for a quadcopter. I was worried about the GC and it looks like as long as I’m really careful about allocating memory (strings, buffers etc.) I should be okay. It will be like writing code for embedded micro controllers (V25 & HC11) in C not long after I left university,
Have also been reading up about proportional-integral-derivative controllers (PID controller) here and building a basic C# implementation.
Next step some PWM code for interfacing to my Turnigy Multistar 10 Amp ESCs. I wonder if my larger scale quadcopter will cause any issues?
I had been considering using the Quadcopter IMU to drive the execution of the orientation and stabilisation algorithms. The MPU 6050 has an interrupt output which can be configured to trigger when there is data available to be read etc.
I had read discussions about the maximum frequency which the Netduino & the NetMF could cope with and just wanted to check for myself. For this test I assumed that the PWM outputs (once initialised) consume little or no CPU and that with only an InterlockedIncrement in the interrupt handler that these would be the maximum possible values.
I used the onboard PWM (D3) to drive an interrupt (D1) and then had a background thread display the number calls to the interrupt handler in the last second. The button (D4) in the picture above allowed me to increase the frequency of the PWM output in 100Hz steps. The desired count and actual count where displayed using Debug.Print and the .Net Microframework deployment tool
100 101
200 107
700 453
1000 867
1500 1225
1800 1629
2100 1943
2900 2470
3200 3093
3600 3432
4000 3799
4000 4020
4000 4021
4000 4020
The counts seemed to be reasonably accurate until roughly 13KHz then there would be major memory allocation issues and the device would crash.
The quadcopter will need to determine it’s orientation then update the thrust to be delivered by each motor many times a second. So I was interested to see how fast my Nedtduino plus 2 could read data from the MPU 6050 accelerometer & gyroscope. I stumbled across this blog and it appears that they are building a Quadcopter as well(Google translation was hard work to read).
There was also some very useful C# NetMF code which I used as the basis for my performance test harness.
10,000 readings of 16bit values from the Accelerometer (X,Y,Z) Gyroscope (X,Y,Z) and temperature sensor. The initial run didn’t look to positive
21.78, 21.77, 21.77, 21.77, 21.77, 21.77, 21.77,21.77,21.77,21.77 sec Avg 21.77
Which is roughly 460/sec
I then had a look at the I2C interface code and noticed that the bus speed was set to 100KHz so I increased it to 400KHz
10.33, 10.23, 10.23,10.23,10.23,10.23,10.23,10.23,10.72,10.23 Avg 10.29
Which is roughly 970/sec
I then had a look at the I2C interface code and changed the way that the register values were read so the array of registers to read didn’t have to be loaded.
8.55,8.57,8.55,8.57,8.55,8.57,8.57,8.57,8.55,8.57 Avg 8.56
I think 1170/sec should be sufficient, but I’m going to have a look at the Digital Motion Processor (DMP) capabilities of the MPU6050. This will require significant effort as there currently (June 2013) doesn’t appear to be any NetMF support for this approach.
For testing I’m going to need a shield to mount my MPU 6050 breakout board and connectors for the four motor speed controllers so a protoshield looked like an ideal solution. The netduino plus 2 I am planning to use for the Quadcopter controller has a slightly different I2C setup to the original Netduino & Netduino plus. After some research it looks like the Netduino plus 2 arrangement is the same as the Arduino Uno & Arduino Leonardo with the I2C SDA & SCL pins next to the AREF pin. I did consider using a software based I2C implementation but discounted this because I was worried about performance and additional complexity.
Many of the Arduino/Netduino protoshields currently on sale (June 2013) don’t have the necessary SDA & SCL pins e.g. Sparkfun, Freetronics, Adafruit, Makershed, ladyada etc.
I have sourced 2 x Leoshield from GorillaBuilderz in Australia which look suitable.
The 3 x MPU 6050 breakout boards (GY521) I ordered on Alibaba arrived from China yesterday. I’m looking at using a device which has both an accelerometer & gyroscope in one package rather than an IMU assembled from several discrete devices to make the software simpler (only one I2C bus address).
To make the Microsoft I2C implementation work with multiple discrete devices usually requires a layer of abstraction like commonly used AbstractI2CDevice class which I was wanting to avoid in this project.
The test rig for my light weight high performance driver, a netduino 2 plus & breakout board.
If I need a compass to make the Quadcopter controller work I’ll upgrade to an MPU 9150.
As part of my quadcopter project I purchased a Netduino Plus 2 for the flight controller. The increased performance 48MHz vs. 168MHz CPU and other improvements looked like it could make it possible to implement most or all of the control algorithms in C#.
So I could compare the performance of the I2C interfaces I setup two test rigs which polled an ADXL345 Accelerometer (using the Love Electronics sample code) 10,000 times for X,Y & Z acceleration values.
The different I2C pins on the Netduino plus 2 required some jumper cables
Both devices were running NetMF 4.2 and I monitored the output of the test harness using MF Deploy.
Netduino Plus
22.2797,22.3126,22.3313,22.3129,22.3590,22.3689,22.3497,22.3049,22.3649,22.3836
Average 22.3 seconds roughly 450/sec
Netduino Plus 2
6.8312,6.8059,6.8003,6.8051,6.8319,6.7999,6.8104,6.8194,6.8233,6.8096
Average 6.8 seconds roughly 1470/sec
A few weeks ago I read a number of conversation on the Netduino and TinyCLR Forums about building a quadcopter. Often there was discussion about how .NetMF wasn’t a viable platform and this got me thinking…
Today, I purchased a Crazyflie Nano Quadcopter Kit 10-DOF as a research platform. I also purchased a Netduino Plus 2 (faster processor than my current Netduino Plus and Fez Panda II boards) and an MPU 6050 breakout board as the start of my control system.
First thing to confirm is that I can read the gyro and accelerometer data from the MPU 6050 at a high enough rate to enable controlled flight. The next step will be to confirm that the processor can process the gyro & accelerometer data at a high enough rate to enable controlled flight.
If these initial investigations are successful start to purchase the parts for a development system based on this Beginners Quadcopter Kit buying guide. I won’t need the remote control hardware (I will use Zigbee or similar) or the controller board.
Using a proven should reduce the risk, plus if I can’t get it to work I can purchase the necessary Openpilot or similar kit and have a working quadcopter.
A few months ago I built a proof of concept NetMF 4.2 application for a client which uploaded data to a Windows Azure Service. Recently we had been talking about extending the application to include support for tagging of the uploaded data with position information.
I purchased a Gadgeeter GPS Module from SeeedStudio and did a trial integration of the module into the client’s application. Initially it was working but I noticed that after a while (I monitored the application using MF Deploy) it would start displaying buffer overflow messages. I did the usual thing and went looking for “slow” code in the GPS events, removed debug print statements and made sure my application and the GPS were “playing nice” but the problem persisted.
My modifications seemed to make little difference so I downloaded the Microsoft Gadgeeter source code from codeplex so I could have a closer look at how the GPS driver worked. (I also personally would also like the driver to return the HDoP, VDoP or PDoP so there is an indication of the accuracy of the position data)
I noticed that there was a GPSTestApp and fired it up to see what would happen. I connected to my FEZ Spider device using MF Deploy and below is the output. The GPS Test application threw an exception shortly after I started it, then started displaying “Buffer OVFLW”. (Odd thing is I it must still be processing some NMEA1803 strings)
I need to do some digging to figure out what’s going on as initially thought it was my code but as the demo application fails I’m not so sure 🙂
Found debugger!
Create TS.
Loading start at a0e00000, end a0e1383c
Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Security.PKCS11 (4.2.0.0) Assembly: System.Security (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: Microsoft.SPOT.IO (4.2.0.0) Attaching deployed file.
Assembly: GTM.Seeed.GPS (1.6.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware (4.2.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1) Attaching deployed file.
Assembly: GHI.Premium.Hardware (4.2.9.0) Attaching deployed file.
Assembly: System (4.2.0.0) Attaching deployed file.
Assembly: Gadgeteer.Serial (2.42.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.TinyCore (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.System (4.2.9.0) Attaching deployed file.
Assembly: GPSTestApp (1.0.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Net (4.2.0.0) Attaching deployed file.
Assembly: System.IO (4.2.0.0) Attaching deployed file.
Assembly: GHI.Premium.IO (4.2.9.0) Attaching deployed file.
Assembly: Gadgeteer (2.42.0.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Attaching deployed file.
Assembly: GHIElectronics.Gadgeteer.FEZSpider (1.1.1.0) Resolving.
GC: 1msec 28272 bytes used, 7311396 bytes available
Type 0F (STRING ): 24 bytes
Type 15 (FREEBLOCK ): 7311396 bytes
Type 17 (ASSEMBLY ): 28176 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
GC: performing heap compaction...
Ready.
Using mainboard GHI Electronics FEZSpider version 1.0
Program Started
#### Exception System.InvalidOperationException – 0x00000000 (4) ####
#### Message:
#### System.IO.Ports.SerialPort::set_ReadTimeout [IP: 0009] ####
#### Gadgeteer.Interfaces.Serial::ReadLineProcess [IP: 0015] ####
Uncaught exception
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
95 x Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
Buffer OVFLW
GPS last position NO POSITION FIX age 10675199.02:48:05.4775807
Buffer OVFLW
Buffer OVFLW
devMobile's blog 