More PWMs?

Hi,

I’m a software guy, so be gentle… :wink: I just bought a Panda-II but have a desire to control 8 brushless ESC motor controllers. Every example I’ve seen of this so far is using the PWM ports. The Panda-II only has 6 PWM ports… Is there a way to add more PWM ports or perhaps a way to control an ESC using the digital I/O ports?

Thanks!

Ian

Look at OutputCompare!

Checkout William’s blog. He has software PWM using OuputCompare.

Thanks guys! OutputCompare appears to be exactly what I’m looking for. Now my next question is… Are there any benefits to using PWM instead of OutputCompare? Should I use the 6 PWMs I have and use OutputCompare on the other two or keep life simple and just do them all the same using OutputCompare? Any benefits either way?

PWM is done with hardware. OutputCompare is software.

PWM is more accurate. OutputCompare can have jitter.

OutputCompare puts a burden on the CPU.

I would use the 6 PWM and then 2 OutputCompare.

Ok. That was my assumption. Any experience with this shield?

http://www.sparkfun.com/products/10615

If I end up needing more CPU or more PWMs would it be worthwhile to offload the PWM ports to?

This is FEZ with 72Mhz processor. In most cases you will not meed that shield but it is good to know there is an option if you need.

It will depend on how accurate and fast you need the 8 motors to change. OutputCompare is great and should handle a moderate update over 8 channels - so for example a robot arm or something like that. It won’t be fast enough for controlling a Octacopter :slight_smile:

By the way, you can control up to 9 PPM servos or speed controllers from a single pin if you use a 4017 decade counter - but maybe you don’t want to add hardware.

What is your application?

I’m starting out with a quadcopter with hopes of expanding out to an octo once I’m satisfied with being able to stabilize with four rotors. I’m not opposed to adding hardware as long as there exists some guidance on how to get it working. I’m a software guy more than a EE and I’m building this mostly as a platform for testing some AI ideas and to have some fun with my kids :slight_smile: Would the shield give me the speed I need for an octacopter? I’m worried about mixing PWMs and OutputCompares since it seems that one will be more responsive than the other and could make it hard to stabilize the copter.

Quadcopters are tricky things.

Here’s a thread of people trying to get a Fez-based one in the air…

http://www.tinyclr.com/forum/1/881/

Here’s one that is already flying - but not sure if it uses a Fez…

http://www.tinyclr.com/forum/20/3651/

If you want to use .Net MF in the core of the solution there are challenges well beyond PWM.

Having said that, that is no reason not to try. I know I am :slight_smile:

And I am ready to help as I really want to see a quadcopter running NETMF

I’ve seen those links and somewhere I saw a video of one actually flying on a netduino. But, I’ve yet to see anything really impressive on NETMF and that’s where I see an “opportunity for success”. I see the whole “it’s not native code” argument everywhere but no measured evidence that it’s actually not realtime enough to make it work. I can see that there’s some quick motion required for a quadcopter to work but from what I can tell it should all be within the capabilities of NETMF. Anyway, I’m up to the challenge and if I can get the thing flying I have a lot of other ideas for NETMF/quadcopter firsts. Let’s get this thing working!

I’m working through some basic tasks (Xbee code, PC test app, etc.) while I wait on the motor/esc/etc. hardware to arrive from Hong Kong… I’ve taken a year or better off from NETMF so we’re easing back into this relationship.

I’m building the remote also. NETMF based also (Tahoe-II). My hope is to fully control it with XBee but I suspect that may not pan out…

Thanks for all the support so far and I look forward to continuing to work together on this adventure.

[quote] I see the whole “it’s not native code” argument everywhere but no measured evidence that it’s actually not realtime …
[/quote]

My personal opinion? This is an excuse from those who tried and failed. Why not compile your “realtime” stuff in RLP on FEZ? Or right into the firmware on netduino? I am not a quacopter expert but if arduino with 16mhz 8bit micro can do it then a 72mhz 32bit FEZ must be able to do a lot more.

We’re on the same I/O port :wink:

Awesome.

I also get upset when people say it can’t be done with MF, but after several months with different challenges I must admit there are some things it just isn’t good at. High speed predictive work is one of them.

See my trial by fire here… http://www.tinyclr.com/forum/2/1835/

You must realise that you have no control over even a simple thing like when the garbage collector will do its thing and kill your timing and

I’ve determined by trial and error that the fastest response time to an external event is about 100uS (10kHz). Executing an instruction takes longer. Add calculations like a PID loop and you can probably spend 500uS from getting input to producing a response to a single channel - never mind 4 or 8. If you consider that the PWM signal you need to produce to control the speed controller ranges from 1.5 - 2.5 ms there is not a lot of time to do anything.

In “native mode” you’ll get order of magnitude better performance. .Net MF is interpreted - not compiled as native code on the chip.

So I think you will need the help of an external module to control the PID loop, or you have to do some of the time critical stuff in RLP or you have to come up with a new way of providing a control loop without using time sensitive PID loops at all. Now that last bit has me interested. Fuzzy logic?, AI? Who says PID is the answer?

A human brain is a lot slower than a Fez Domino - yet it can balance a full scale helicopter with 6DOF or an RC one with sight input alone. How does it do that? If you crack that, then maybe there’s hope for NETMF and quads :slight_smile:

Just because I can’t take “can’t be done” for an answer… http://jp.physoc.org/content/577/1/403.full

Yea, I think you’re on the right track. The trick is going to be to offload the sensor stuff and just let the Panda-II be a “brain” that simply tells the vehicle where to go. This is my first R/C build so I’m learning as I go but my first attempt is going to be offloading this to an AHRS and let NETMF take it from there. This one is at the top of the list right now. I’m going to get some basic structure & control pieces in place before making my final decision and ordering.

http://store.ckdevices.com/products/Mongoose-9DoF-IMU-with-Barometric-Pressure-Sensor-.html

The sensor itself runs Arduino so there is some capability there to customize if needed.

The article looks interesting. I’ll study it tonight and see if it energizes a light bulb.

Didn’t read through the whole thread so don’t jump at my throat if this has already been suggested:

PWM Generator chips. You can get chips controlled by serial/i2c that have anything up to 12 or so PWMs on them, all controlled by a serial signal.

Just type in PWM generator on your favourite suppliers website. In my opinion using software to tackle a hardware problem is a bit iffy.

Maybe it is time to start a new thread on this? Call it “AI Quodrocopter” and I’m sure people will be following it closely.

Personally I’m looking at this IMU:

The problem with all these are they just give you the readings - and don’t apply the PID calcs (which is the really intensive part). That is exactly the bit you need to offload. Getting the serial stream in to MF is not going to help much.

The Mongoose IMU should be a good buddy to RLP - where RLP can get the info and do the PID’s and then get its higher level instructions from NetMF.

I don’t know why everybody is using serial or I2C for this. SPI should be a lot better and should be able to shift 10x 16 bit IMU values into memory in microseconds - by hardware alone.

I’ll be following this with interest. I’d like to have a NetMF quad in the air before the end of the year.

True for an IMU. But, the board I referenced supposedly is a full fledged AHRS (Attitude and heading reference system - Wikipedia) which as I understand it means that it does all calcs for you and just returns the solutions. Again, I haven’t ordered the chip yet and don’t really know what the data looks like but it appears to be promising.

As far as I2C vs SPI, I suspect I’m like a lot of hobbyist out there that have more desire than electronics experience and without your mentioning it I would probably have no idea what SPI is. I2C is the interface most touted in the product descriptions so that’s the obvious place to start for beginners. I will definitely study it.

AI in quadrocopters is certainly not a new idea. Have you seen this video?