.NET Hacker Room at Code Impact

If you haven’t done so yet, you should register for Code Impact up in Jacksonville on September 13th.

I’ll be hosting a new tradition in FL Code Camps a .NET Hacker Room.  A .NET Hacker Room is a unique experience that will allow you to see and play with some of the latest hardware technology.  

This room will offer things like
- Internet of Things
- 3D Printers
- Quad Copters
- Windows Galileo
- Robots
- Netduino's
- Oculas Rift (V2)
- More!

Also throughout the day, come in for 10-15 minute lightening talks on the above topics.

See you there!

-twb

Controlling a Netduino Robot with BlueTooth

For our April meeting, we will be controlling our Home-Built robot with a Windows Phone device, this should fun so hang on!

We will be using this Bluetooth Module

http://www.amazon.com/Arduino-Wireless-Bluetooth-Transceiver-Module/dp/B0093XAV4U/ref=sr_1_1?ie=UTF8&qid=1395938505&sr=8-1&keywords=Bluetooth+module

And the following USB Serial Port Adapter

http://www.amazon.com/SunFounder-Arduino-Program-Download-Mega2560/dp/B00GD6GE6O/ref=sr_1_10?ie=UTF8&qid=1395938602&sr=8-10&keywords=USB+232

First thing we need to do is configure our BlueTooth Module.

1) Power your Bluetooth Module with your Netduino

VCC –> +5V (Netduino)
GND –> GND (Netduino)

2) Connect your BlueTooth module to your FTDI Serial Adapter

FTDI  Netduino   BlueTooth Module
GND   GND
TX                          RX
RX                          TX

3)  Open up Device Manager, and identify the serial port that is associated with your FTDI adapter, in my case it’s COM16, yours will probably be something like COM4.  A good way to identify your adapter is to unplug, then plug it back in.  The one that disappears and reappears is probably the one you want to look at.

3) Download and start RealTerm

4) Configure the initial baud rate of 9600 on the “Port” tab, then press “Change” and “Open”

5) Confirm that your port is open and the correct baud rate is set at the bottom of the screen

6) If all that looks good, then we can start to configure our BlueTooth module, commands need to be sent very quickly.  The best way to do this is open up Notepad or some other mechanism where you can enter text and then cut and paste it.

a) Open Notepad
b) Type AT
c) Copy those two characters on to the clip board by highlighting them and hit CTRL-C
b) Right mouse click in the terminal area in RealTerm, and click on “Paste to Port”
c) If all goes well you should see OK

7) Once you know you are connected, enter the text AT+NAMEXXXXXX in notepad, where XXXXX is the name how you want to identify the bluetooth device.  No CRLF at the end.   Then copy those characters and paste them into RealTerm.

8) Then set the PIN by doing the same thing with AT+PINXXXX where XXXX is the 4 digit PIN used to pair with the device. IMPORTANT NOTE: If you use a PIN code like 1234, or 0000 your phone may try to auto-pair with that value.  To get it to work successfully in your app you will need to enter a more non-traditional code, and then manually enter the PIN code via BlueTooth settings.

9) Once you have completed your screen should look very similar to the following.  Your settings will automatically be saved to the device and you can continue by connecting it to your Netduino.

Connect the BlueTooth module to Netduino

10) Now you need to connect your BlueTooth module to your Netduino, you can remove the wires from the USB FDTI and connect them to the Netduino.  See PDF here for a better view of your Netduino

BlueTooth Module  Netduino COM1
RX                              PIN 1 (TX) - D1
TX                              PIN 0 (RX) – D0
VCC                           +5V (from before)
GND                           GND (from before)

11) Next up is to connect to your BlueTooth device from your Windows Phone 8.  You will have to use an actual device, not a simulator.  Hopefully you know how to do this, but click on Settings->BlueTooth, make sure it’s turn on, and find the name of your bluetooth module.  Make sure you enter a PIN code, if it automatically pairs you may have used a known PIN such as 0000 or 1234, try something different in step #8 above.

12 After you have paired your device, download the following Windows Phone 8 application and make sure you can compile it and run it on your device.  Make sure you change the name of the device in MainPage.xaml.cs to match the name of our BlueTooth Device

13) Then download the .cs file that has the code, to insert into your .NET Microframeworks project, the code is very straight forward, just cut and paste the appropriate parts into your application.  Also, just populate the code in your project to make the inputs from your phone actually do something.

 

At this point, your little app should be ready to run!

 

14) Next download the Windows Phone 8 project.

Enjoy

-twb

.NET Microframeworks Group and Windows Phone/Windows Store Apps

In our continuing serious on building an autonomous vehicle, in April we will let you robot start talking to the real world!

On April 15, I’ll be doing a session on demonstrating how to remotely control and talk to your robot from a Windows Phone and Windows Store application by adding a Bluetooth module to you robot.  And then setup some very basic protocols to control your robot with a Windows Phone and Windows 8 application. 

You'll be able to get the Bluetooth device from Amazon: 

http://www.amazon.com/Arduino-Wireless-Bluetooth-Transceiver-Module/dp/B0093XAV4U/ref=sr_1_1?ie=UTF8&qid=1395938505&sr=8-1&keywords=Bluetooth+module

To use this Bluetooth module, you'll need to configure it, to do so, you'll need some sort of USB to Serial Port Connector such as:

http://www.amazon.com/SunFounder-Arduino-Program-Download-Mega2560/dp/B00GD6GE6O/ref=sr_1_10?ie=UTF8&qid=1395938602&sr=8-10&keywords=USB+232

You can sign up at:

http://www.meetup.com/Tampa-Bay-NET-Microframeworks-Developer-Group/events/173765942/

-twb

NiVek GO! QC1 – Part 4, Lessons Learned (to date)

Yesterday was my first public power-up demo of NiVek GO! QC1 at South West FL Code Camp.  At this point, I’m very happy with the state of all the software components created, they seem to be very stable and fairly robust and have plenty of band-width for future enhancements.  The following are the primary chunks of software I’ve developed for my Quad:

• Three GO! modules written in C – one for reading sensor inputs at 200Hz, another for communicating via WiFi and a third for controlling motors and reading inputs from the RC Controller.  All this software is running on STM8S207’s micro controllers running at 16MHz.  These have 32KB ROM, 6K RAM and a little bit of EEPROM.
• Netduino GO! “Command-and-Control” software written in C#.  This software communicates between the modules and really provides orchestration of all the sub processes that make up the Quad.
• Flight Console – written in C# running on Windows 8 as a Metro, er-ah, whatever they end up calling the new style tablet apps for Windows 8.

At this point I have all the software controlling the hardware but I’m struggling with the most complicated part (at least for me to-date) in building my quad, achieving stable flight.  I’m actually getting fairly good results now with my test rig running on a single axis, but attempting to get more than a few inches off the ground and maintaining stability is turning out to be more challenging that I expect.  Remember the goal here is NOT to use the RC controller to control the pitch and yaw, but to measure the error and then update the power to the corresponding motors to compensate for those errors.  The RC controller (and eventually the Windows 8/Windows Phone apps) will be used to send a command to the “fly-by-wire” system of the quad.  Then the quad will figure out what it needs to do to make those commands happen.

Lessons Learned and Next Steps -

Noise on Accelerometer

One of the biggest differences I’m seeing between just developing the software on a development board and using it on the quad with the motors running is the amount of noise in the accelerometer.  With a low pass filter of about 10Hz running, I’m seem very stable output from the accelerometer without the motors (+/- 0.25 degrees).  With the motors running, I’m seeing unacceptable noise of about +/- 10 degrees.  Since gyro is extremely stable and the accelerometer is only used to compensate for drift, the accelerometer doesn’t have to be super accurate and noise free, but it does have to be better than +/- 10 degrees.  I haven’t tracked this down to be electrical or mechanical, however here are my next steps to minimize the noise.

1. I have some new boards coming next week where I spent considerably more time thinking through the ground plane and adding bypass capacitors.
2. My current quad frame is plywood, I’m going to try a different one that is aluminum with a carbon-fiber deck for mounting the electronics.
3. Add some small rubber washers to attempt to isolate the electronics.
4. Add some small rubber washers to connect the motors to the frame.
5. If I’m still seeing the noise, I’ll take a look at balancing the propellers.

Update rates on the ESC.

I’m currently using the stock firmware on the ESC (electronic speed controls) that are used to take the output from the micro controller and power the motors via PWM.  The stock firmware only allows an update rate of 50Hz to control the motors.  In addition, after doing some research, I’m seeing that this is even filtered a bit more and I might only be getting about a 20Hz update rate, this really doesn’t seem fast enough.   I found a great post on RC Groups that discuss how to flash new firmware on my ESC’s that should allow for a faster update rate.  This still uses PWM but looks like it might allow and update rate of 400Hz which would be fast enough for the system to grow into. 

As a couple sides notes on this:

• Since it looks like I’ll probably end up flashing the ESC’s I might look to using something other than PWM to communicate with the speed controllers.  It doesn’t seem like it might be all that much of a stretch to go to I2C or even something really crazy like using a custom GO! module with some FET’s, but this probably won’t be something that will happen in the near future.
• The firmware I’m going to flash is actually written in assembler.  It probably sounds crazy, but I really wouldn’t mind getting my hands dirty and seeing what I can do to really make my ESC’s play nicely with my GO! module.  I never thought I’d see the day when I would have the need to write assembler again.
• Right now I’m only using 100 graduations from idle to full throttle.  That is to say I can only specify an integer value of 0 to 100% to control the PWM and thus the speed.  My initial gut (which is usually correct) says that resolution is probably the best I can expect from the ESC/Brushless motor combination.  However now that I’m seeing the quad in action with the motors running, it almost seems like small difference actually make a bigger difference in the RPMs.  I might want to do some tests, I’m thinking I can use some sort of IR Sender/Receiver and a little app that counts pulses, then I could measure the RPM of the propeller and see how it response to different inputs.  This would also be very “interesting” from a before-and-after perspective of updating the firmware on the ESC’s.

 

Allow for additional configure of the sensor and GPIO module.

• The accelerometer and gyroscope have some register based settings to control things such as filter frequencies and update rates.  Right now these are set as constants in the firmware.  These can just as easily be read from the EEPROM after being programmed from the flight console (similar to how the PID values are being configured).
• The accelerometer has a high-pass filter implemented on the STM8 that should be configurable via the flight console.
• The complementary filter has some constants on how the Gyro-scope and accelerometer are combined.
• There are at least two common approaches to combine the gyro and accelerometer.  I chose a complementary filter since it was easier to implement and doesn’t require as many CPU resources as a Kalman filter.  Since it looks like my little STM8’s aren’t working that hard, I might go ahead implement the Kalman filter or investigate the “Extended Kalman” filter has demoed in this video.
• Right now the PID constants are linear.  That is to say, the P or proportional component applied to the error is the same if the error is 20 as it is if it is 2.  Might want to consider having two sets of PID constants, one for “really-bad” errors, this will probably only use the P component.  Then when we get to the point where we want to fine-tune the correction factors, have a different algorithm or set of constants.

I have a fairly large client deliverable due in September but hope to have the majority of the items completed by the end of the month.

-twb

NiVek GO! QC1 – Part 3, Test Fixture/PID Controller

In my continuing effort to get my .NET quad copter off the ground, I’ve created a quick video to demonstrate the test fixture and software I’ll be using to achieve staple flight.

Enjoy!

NiVek GO! QC1–PID Tuning Fixture

-twb

Tampa Bay – .NET Micro Framework Development Group

Today I’m announcing the first meeting for the Tampa Bay – .NET Micro Framework Development group on Thursday October 18th, 2012 at the Microsoft Office in Tampa.

If you’re interested in learning more about controlling hardware for software, even if you have no experience, please join us!  You can read more about the .NET Micro Framework.
These will be the primary goals of the first six months or so of the meetings (which are open for discussion):

• Setting up development environment, the hardware and software you will need.
• Very basic digital electronics, how to flash an LED, how devices and components talk together.
• Communicating with a Windows 8 and Windows Phone front end.

These meetings will be part “lecture” where we’ll discuss some basic concepts and potentially do some hands-on exercises as well as “show-and-tell” that will let folks do quick demos of fun stuff they are working on.
To start out with, we will be working with the first generation Netduino, so if you are interested in hands-on participation, you might want to order one of these before coming to our meeting.
Even if you have zero experience, but have an interest in this kind of stuff, please come and join us!  It really is an awesome experience bringing hardware to life with the software you write.
RSVP Now
-twb

NiVek GO! QC1 Video – Part 2

Here's another quick and dirty video of NiVek GO! QC1 a .NET Microframeworks application with a Windows 8 (and coming soon Windows Phone 8) Flight Console

In this one, I'm spinning up the four motors on the quad copter although I'm a little timid to try to fly it in the cramped quarters.

 

As noted in the video, I'm seeing a lot of noise in the accelerometer when I power up the motors, but the gyro is clean.  Using a complementary filter I'm getting decent attitude readings (pitch/roll), but it's still bouncing around a couple of degrees, if anyone has any suggestions on how to isolate and cleanup the problem, I'd love to hear them :)

Next up is hook in the pitch/roll or error information into the PID controller and see how it flys.

Stay tuned!

-twb

NiVek GO! QC1 - Part 1

As a follow up to my initial post on NiVek GO! QC1, I shot a quick and dirty (read as: one-take and no editing) of the software and hardware working together to control a brushless motor and display sensor outputs from the Gyroscope and Accelerometer.

NiVek GO! QC1–Part 1

-twb

NiVek GO QC1 Makes its debut at Tampa Windows 8 User Group Meeting

On August 8, 2012, the NiVek GO! QC1 (Quad Copter1) built with Microsoft .NET technologies will make it’s debut at the Tampa Windows 8 User Group meeting. 

You may ask what does a Quad Copter have to do with Windows 8?  Well, the flight console as pictured below runs on a Windows 8 Slate.

Not 100% a metro app, but it’s not a typical application either

The “brains” or flight computer behind the quad copter is really in four parts.  Yes, that’s right there are four processors use to power the copter. First is a board I designed that has 3 STM8 chips a bunch of sensors and some EEPROMs used to keep data when the power is pulled.

The second is the new Netduino GO! board

You can see how they are connected in the following picture, via something called SPI.

Do you really need four processors?

You may ask, does it take four processors to drive a Quad Copter.  The answer is: well probably not, however a quad copter is inherently unstable and it does require a good amount of processor power to provide a “fly-by-wire” mechanism to keep it stable.  The idea here is to use a modular approach where each processor has an assigned responsibility, it does only one or two things and it does them very well (or what’s important here, very fast on a very highly predictable time frame).

What do each processor do?

GO! Main Board – The Netduino GO main board provides orchestration of flying the copter.  The software for this is primarily written in C# running on the Microsoft .NET Micro Framework. Not really time critical things but more strategic.  Things like routing messages between the different modules.   Considerably more on this to come in future posts

Sensors Module – It’s one responsibility is to figure out the attitude of the quad copter, that is to say the pitch, roll and yaw.  This also has sensors for altitude and a GPS.  The sensors in the first generation of my board are a 3 axis gyro ITG3200.  A 3 axis accelerometer and 3 axis magnetometer (electronic compass) LSM303DLHC.  A sensor to measure air pressure (which can be used to accurately determine altitude) BMP085.  And finally a fast GPS module (10 updates per second) UP501.

Flight Control Board – This really has three main functions:

1. Quad copter is flown by a standard Remote Control transmitter.  The first task of the flight control board is to take the PWM (Pulse Width Modulation) from the receiver and turn it into inputs for the flight control computer.
2. Next step is the fly by wire algorithm.  This takes the current attitude (how much the quad copter is tilting in the X/Y plane) and combines that with the input from the RC receiver and figures how how much power needs to be applied to each motor to keep the Quad Copter from crashing.
3. Finally the Flight Control board takes the power to be applied to each motor in the form of a percentage and changes that into another PWM signal that is applied to the ESC (Electronic Speed Control) that controls the brushless motors.

Telemetry Board – The primary purpose of this board is to establish a link from the on board computers back to the Windows 8 (and eventual Windows Phone 8) consoles.  This uses the RN-171 WiFi module and an STM8S207 chip to provide these services.  This modules purpose is very simple, take a byte array in very quickly via SPI, buffer it and then send it out via WiFi.  It also listens for commands from the flight console and relays them to the GO! main board for processing. 

Couple final pictures

This is the control board mounted on the Quad Copter Chassis.  The white stuff is the Gorilla Glue I used to hold everything together.  Didn’t realize how much of a mess it would make .

 

Close up of the Brushless motors and the 10” propellers.

What’s next?

Tonight I only have a brief amount of time to cover this project, for a more detailed run through of the hardware/software, please attend my session at the SWFL Code Camp in Napes on September 8.  I’ll probably be flying it over lunch.

In addition over the next couple of months look for many more posts along with the publishing of the hardware and software for the NiVek GO! quad copter platform.

Until next time!

-twb