Javascript Disabled Detected

You currently have javascript disabled. Several functions may not work. Please re-enable javascript to access full functionality.

The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

NetDuino Quadrocopter

Started by Brandon G , Jan 02 2011 09:32 PM

Prev

Next

Please log in to reply

75 replies to this topic

#41 Mark H

Advanced Member

Members
70 posts

LocationPerth, Western Australia

Posted 14 January 2011 - 02:54 PM

It will be interesting to see how the quad goes purely on a Netduino. That fezzer code is Chris Seto's btw (His TinyCLR user is simply "Chris")

Back to top

#42 dones

New Member

Members
3 posts

Posted 14 January 2011 - 03:11 PM

It will be interesting to see how the quad goes purely on a Netduino. That fezzer code is Chris Seto's btw (His TinyCLR user is simply "Chris")

Ah, that would explain the ChrisSeto namespace that I didn't notice before. I think I know one person I will be posing questions to as I progress through .NETMF land! I wonder why he uses his kid's picture for his avatar?

Back to top

#43 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 14 January 2011 - 04:38 PM

dones, thanks for the PID link. great point starting with just one plane might be easier as a proof of concept, I was thinking of doing some simple tests with the gryos before i considered flying at all. a simple 2 prop setup might be a good way to start. Jan I will look at them more deeply, my understanding was they using one gyro for each roll pitch yaw and that they were being sent back to the controller for pid changes, they had basically taken those things apart and done a straight sodder to their custom board, they were chosen because they were cheap and they had the best success with them. I have read sparkfuns gyro acceleromter guide and man is it thorough, my hope was to go with what was proven out there and follow their same steps. Sparkfun has some great ones with 3 axis in one that would be ideal for this application but are more expensive and a more of an unknown but if your above post is correct then may be the way i need to go

Back to top

#44 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 14 January 2011 - 05:01 PM

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

Good call. BTW, the quantum is a constant and can be changed in code. We've never tried increasing it but it could be possible to increase it to, say, a few weeks/months. If everything is executing on a single thread and one is not using events or threading, this could be a valuable mod.

Chris

Back to top

#45 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 14 January 2011 - 05:43 PM

gryo disassembly http://www.kkmultico...embly&Itemid=65 they are just using what they need

Back to top

#46 Jan Olof

Advanced Member

Members
41 posts

LocationSweden

Posted 14 January 2011 - 05:51 PM

Ok Brandon, You are not using the HK401B as a unit, just as a donator of parts (the gyro). Interesting. /Jan Olof

Back to top

#47 Chris Seto

Advanced Member

Members
405 posts

Posted 14 January 2011 - 06:28 PM

Please note that that PID controller is not Pole-Zero Canceling, I have a version that is, but I have not been able to test it due to not being about to run my autopilot in the WX conditions that envelop Missouri around this time of year. I have a newer, better version that will be available as soon as it decideds to warm up a bit.

Back to top

#48 dones

New Member

Members
3 posts

Posted 15 January 2011 - 12:17 AM

Hi Chris, earlier you had mentioned that you have a quad of your own. Did you write your own FC firmware, or are you using an existing platform? Just curious, thanks! Edit: Sorry for the dumb question, I just went back and read your original post and see that you are building it custom. Do you have a build blog/site anywhere?

Back to top

#49 Chris Seto

Advanced Member

Members
405 posts

Posted 15 January 2011 - 12:58 AM

The quadcopter I own was designed by myself and my project partner. My project partner did/is doing all of the MechE related tasks including the airframe assembly, while I am working out the EE aspects of the aircraft. For right now, we are using an Aeroquad board, however I am only going to use that board to learn how to handfly the aircraft, and then I will be creating a new FCU based on an FPGA/Prop and a NETMF target using custom FW. At this point, we are awaiting the final shipment of parts.

Back to top

#50 Chris Seto

Advanced Member

Members
405 posts

Posted 15 January 2011 - 01:14 AM

I wonder why he uses his kid's picture for his avatar

That's me, granted the picture is maybe around a year old, I look very young for my age and I always have.

Back to top

#51 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 15 January 2011 - 01:17 AM

That's me, granted the picture is maybe around a year old, I look very young for my age and I always have.

I think 'dones' was just teasing. [For reference, I apparently look about 3-5 years younger than my age as well. On my first driver license, I looked like I was in elementary school still.

]

Chris

Back to top

#52 bill.french

Advanced Member

Members
260 posts

LocationPrinceton, NJ

Posted 15 January 2011 - 03:17 AM

I think 'dones' was just teasing. [For reference, I apparently look about 3-5 years younger than my age as well. On my first driver license, I looked like I was in elementary school still. ]

Chris

Whoa, after meeting you at Maker Faire, I never would have guessed you were in your 50s!

Back to top

#53 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 15 January 2011 - 03:33 AM

Whoa, after meeting you are Maker Faire, I never would have guessed you were in your 50s!

Clever, Bill French. Clever.

Back to top

#54 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 16 January 2011 - 09:42 PM

Have started some source control on this, just taking some initial stabs at getting a nice generic framework put together for project. Separating hardware / frameworks from implementations as a trial of framework i put in chris setos old esc driver code with some modifications, havent tested it against any hardware nor put in test cases but wanted to assert the structure first then will deal with implementational details later starting pooint of code is Quad.Net.FlightController.Implementations.Netduino PM me for address, it should be a readonly right now, but as i get things solidified i would like to open it up to contributions, thoughts/criticisms always welcome

Back to top

#55 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 16 January 2011 - 09:44 PM

Good call. BTW, the quantum is a constant and can be changed in code. We've never tried increasing it but it could be possible to increase it to, say, a few weeks/months. If everything is executing on a single thread and one is not using events or threading, this could be a valuable mod.

Chris

Chris where do i change this setting?

Back to top

#56 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 16 January 2011 - 11:51 PM

http://forums.netdui...pter-for-netmf/

Back to top

#57 CW2

Advanced Member

Members
1592 posts

LocationCzech Republic

Posted 17 January 2011 - 02:07 PM

Chris where do i change this setting?

The constant is defined in Porting Kit header file CLR\Include\TinyCLR_Runtime.h, line #2376 (static const CLR_UINT32 c_TimeQuantum_Milliseconds = 20).

...it could be possible to increase it to, say, a few weeks/months. If everything is executing on a single thread and one is not using events or threading...

But how about hardware events, such as interrupt-based GPIO or communication (UART, SPI, I2C etc.)? CLR checks for any hardware events in between scheduling managed threads, so long quantum will cause long response times for such events.

Back to top

#58 Chris Walker

Secret Labs Staff

Moderators
7767 posts

LocationNew York, NY

Posted 17 January 2011 - 04:27 PM

But how about hardware events, such as interrupt-based GPIO or communication (UART, SPI, I2C etc.)? CLR checks for any hardware events in between scheduling managed threads, so long quantum will cause long response times for such events.

Good question. For many of these, this is actually handled "real-time" in the background and the data is buffered. But serial data can be retrieved by using SerialPort.BytesToRead and SerialPort.Read(...) instead of SerialPort.DataReceived, etc. Much like is done on traditional microcontrollers.

There will still be some background processing that's done if a user were to mod the firmware with a long quantum, go single-threaded, not use events, and remove GC from the equation. UART hardware interrupts for instance. We'd have to do some testing to find out the real impact of these...

Chris

Back to top

#59 Brandon G

Advanced Member

Members
92 posts

LocationVancouver BC, Canada

Posted 21 January 2011 - 05:14 PM

A guru buddy of mine suggested that F# would be perfect for the stab loop part of the program and saidi would be able to use F# as long as the calling assembly (entry point) was still in C#. So the C# program would call into and F# dll, since it all compiles to the same binaries it shouldnt be an issue. I would assume the same can be done with VB, listen to http://www.dotnetroc...spx?showNum=625 where they speak about VB