75 replies to this topic

[Mark H]

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")

[dones]

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?

[Brandon G]

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

[Chris Walker]

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

[Brandon G]

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

[Jan Olof]

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

[Chris Seto]

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.

[dones]

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?

[Chris Seto]

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.

[Chris Seto]

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.

[Chris Walker]

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

[bill.french]

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!

[Chris Walker]

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

Clever, Bill French. Clever.

[Brandon G]

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

[Brandon G]

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?

[Brandon G]

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

[CW2]

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.

[Chris Walker]

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

[Brandon G]

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

[Brandon G]

a small test shows he's wrong, too bad was worth a try