Jason,
Almost all ESCs are "programmable/configurable" and people have figured out the protocols for this with some brands. It could be used to detect the ESCs and even configure them via code.
Here is a site with the info & code for Turnigy ESCs (the ones in the ELEV-8 kit are this brand): http://www.frank-zhao.com/cache/escprogrammingcardhack.php
I suspect that a number of them use the same protocol even, because people have mentioned being able to use programming cards from some brands with other brands.
Cluso99: that board setup looks decent. Some comments: You might want to consider making the mounting holes on the main board a little larger so you can put rubber grommets in it and then fit a screws thru them for mounting to help reduce vibrations (the hoverfly boards have this setup, see what I'm talking about in this image: http://static.rcgroups.net/forums/attachments/7/5/0/7/4/a4152448-124-IMG_4534.jpg ). Also, the sensor daughter board needs to be mounted solidly, I think you have those small holes at the opposite end from the connection header end that line up with the same size holes in the main board for this? Is the idea to solder in some posts?
Roy - thanks for that - I have TowerPro (acro series) ESCs because they have a programmable throttle range (no startup init required), and they too have a programming box. I'm curious to see if the programming matches. Since it's easy to program the ESCs externally I probably won't do this right away, but it certainly would be a nice feature.
Ken (and all) - I've updated the screen shots for my fully working QuadX Ground Station. The programming all works. I'll have to test the flight config (+ or x) by physically changing my quad temporarily, but it should all work. I'll also have to make sure that my pin choices are HoverFly compatible. The high-speed servo code is hard-wired (partially), but everything else I could configure easily in code.
Jason,
I was thinking that you could use that protocol stuff to just detect if an ESC was present on the connector. Perhaps just do one of the commands to read the settings out (like the card does), and if it responds then you know an ESC is there. The Hoverfly boards do something to detect the presence of the ESCs and goes into an error state if one or more is missing.
I did another flight today with my latest changes. The fast ascent / descent wobble is still there, but it's reduced significantly. It used to wobble and oscillate badly during just about ANY descent, so this is a marked improvement.
Descending into your own turbulence may require enough power to correct that the correction causes the prop to momentarily stall, which would begin a cycle.
Helicopters have the same issue, but since they only have one rotor it doesn't usually affect stability - it just means you need more power to climb out after a descent than you would to hover normally.
By descending in place, you create a downward moving column of air that pulls you with it, and it's turbulent to boot. In a single-rotor heli, applying normal power may not overcome the downward speed of the air column, so you need more power just to stop the descent. In a multi-rotor, each rotor has the problem, and turbulence compounds it because they won't all see the same turbulence at the same time, making it more unstable than usual.
I call it "the descent sonic boom". :-) I was happy just to make the effect less pronounced.
My rapid ascent problem is more likely one of balance or vibration resonance. If the weight isn't properly centered, applying full power to all the props may make it tip. It should recover from that though, so I suspect it's the latter - higher motor speed hitting a resonant frequency of the gyro sensors and causing false tilt readings. I'll never know for sure unless I start recording my flight data to SD card.
Helis have the settling with power or vortex ring state problem when descending too quickly. It's a little different in that the flow pattern through the rotor disc is reversed in areas. The quads should not have reversed flow at all. An RC heli can get out of it through sheer power but a full size needs to fly out of it.
It should be easy to rule out. If you add some weight and it gets worse then that would point to stalling - if it doesn't then it is something else.
I don't think I was paying attention when I read that the prop might momentarily stall - You're absolutely right, that could be it. I should try flying with a single battery and see if it gets better - that's an easy test for me.
Today it finally happened - we hit the HR manager's BMW. There was no damage, but it was a close call! Nick was flying around and somehow got a bit sideways on the landing and crashed into the wheel, leaving a broken propeller nicely stuck between the wheel and tire. The ELEV-8 bounced off the wheel and Daniel started jumping up and down. Unfortunately, the HR manager saw the whole event unfold from her office. When we came inside the office there was a meeting (and a confession):
To lighten the mood, HR manager was invited to record a crash for Nick on the whiteboard. Nick had at least 30 flights before this crash.
Let's hope for brighter days, and maybe that BMW will get parked on the other side of the building.
I'm laughing because I've been there. I've been flying with friends on more than one occasion and had someone's plane go into one of our cars. Thankfully there's been no significant damage as usually the planes are styrofoam and take the brunt of the impact. I'm pretty paranoid with the quad when flying in anything but an open field, and if any kids come over to watch, I ask them to stand behind me (or the imaginary line I'm on). I figure if it has to go through me to get to them, I'm a lot less likely to hurt someone.
Jason,
Almost all ESCs are "programmable/configurable" and people have figured out the protocols for this with some brands. It could be used to detect the ESCs and even configure them via code.
Here is a site with the info & code for Turnigy ESCs (the ones in the ELEV-8 kit are this brand): http://www.frank-zhao.com/cache/escprogrammingcardhack.php
I suspect that a number of them use the same protocol even, because people have mentioned being able to use programming cards from some brands with other brands.
Cluso99: that board setup looks decent. Some comments: You might want to consider making the mounting holes on the main board a little larger so you can put rubber grommets in it and then fit a screws thru them for mounting to help reduce vibrations (the hoverfly boards have this setup, see what I'm talking about in this image: http://static.rcgroups.net/forums/attachments/7/5/0/7/4/a4152448-124-IMG_4534.jpg ). Also, the sensor daughter board needs to be mounted solidly, I think you have those small holes at the opposite end from the connection header end that line up with the same size holes in the main board for this? Is the idea to solder in some posts?
Roy,
This code for the Atmega 328 only simulates the Turnigy programming card which cannot set the ESC upper and lower end points, at least my Turnigy card can't. Jason requires that the ESC upper and lower set points be established for his code to work correctly if I am not mistaken.
Regards,
TCIII
Roy was just suggesting it as a way to verify the presence and correct operation of the motor controllers. Most of these ESCs have a "power on with full throttle" option to sense your maximum and minimum stick positions. I've already accounted for that in my flight code and setup program. I've just ordered a bunch of ESCs that work this way to test it on.
Ken - Got your email. In prep for the board, I don't suppose anyone can tell me which pins the HoverFly board uses for the ESCs, R/C connections, gyro, and accelerometer? If you have a schematic or document with it just point me at that.
Tom C:
The primary thing I was hoping for with the code was a way to detect if an ESC was connected or not. Being able to program it was secondary. Also, I'm sure with a logic analyzer and some time we could figure out the rest of the protocol to be able to set the upper and lower points and any other thing. If we get enough cards/ESC pairs to test with we could determine all the protocols. They all have to work over 1 signal wire, so it can't be terribly complex, and it's likely to be very similar for all of them.
Jason:
I have a plain (passive - no prop) servo pcb ~1.8"x1.2" that has a 16pin servo header with series resistors and individual 5V jumpers. See my website for a pic (link in signature). PM me your address if you would like one (normally 10-14 days by post from Oz but its xmas so maybe longer ATM). Alternately, Ken may not be using the one I sent to him if you are close to him. I am also using my Prop BaseBoard1 that this plugs into. Forget if I sent one to Ken too. Anyway I can send you one too if you would like.
My new pcbs are in production but I will not see them here for 3-4 weeks (takes 2 weeks+ for the post)
I have wondered if it would be possible to easily modify the extra channels on the RC transmitter to send a varying pulse width rather than on/off, perhaps as simply just fitting a pot instead of the switch. That way, you could dynamically vary some of the PID values.
I've also done a bunch of reading, and found that the small satellite receivers for Spektrum receivers can be used on their own - they're SPI, and the protocol has been reverse engineered. I plan to write a driver for it so it'll be "as many channels as you have" on a 3-pin JST. That's not a requirement, but it'd be pretty cool.
Great - I have a Spektrum DX6i so I have a satellite rx. Oh for the time to try it!
ESCs:
It is my intention to next design a tiny pcb to control 4 brushless motors with a prop. Two boards can be stacked for hex or octa copters. This way we will have total and fast responsive control of the motors (and feedback of motor revs for logging). However, this is little way off yet.
BTW this solves another problem too... that of power distribution. So the inclusion of the prop should not add any cost over separate cheap ESCs costs.
Cluso99: that board setup looks decent. Some comments: You might want to consider making the mounting holes on the main board a little larger so you can put rubber grommets in it and then fit a screws thru them for mounting to help reduce vibrations (the hoverfly boards have this setup, see what I'm talking about in this image: http://static.rcgroups.net/forums/attachments/7/5/0/7/4/a4152448-124-IMG_4534.jpg ). Also, the sensor daughter board needs to be mounted solidly, I think you have those small holes at the opposite end from the connection header end that line up with the same size holes in the main board for this? Is the idea to solder in some posts?
Thanks for the info Roy. I was aware of the vibration issue from the forums on other cpu solutions.
The mounting holes are 3mm but a 2mm screw and grommets could be used. However, the pcbs are designed to mount in a Hammond 1551R/S 2"sq box to protect it. The lid is underneath the pcb, with the main part of the box sandwiched on top of the pcb. The base of the main part of the box needs to have openings cut for the servo connections. This box may in turn be mounted with the appropriate grommets or whatever for the vibration issue. Perhaps double sided tape will also work - I am trying this on my existing pcbs.
The sensor daughter pcb is desiged, as you correctly determined, to have the other two pins on the other corners also soldered to the main pcb. While they can be in a socket, my preference is they be soldered. The 2 holes on the connector side are larger and will IIRC take 2mm screws for alternate mounting (perhaps they may be used with other pcbs).
My new pcbs are in production but I will not see them here for 3-4 weeks (takes 2 weeks+ for the post)
I have wondered if it would be possible to easily modify the extra channels on the RC transmitter to send a varying pulse width rather than on/off, perhaps as simply just fitting a pot instead of the switch. That way, you could dynamically vary some of the PID values.
I've got my hands full with the stuff I've got, so I'll wait for the new boards. My 9-channel remote does have additional analog controls, and they can be fed to any of the extra channels, or mixed with existing ones. I have one set to fine tune the throttle to help when hovering, but they'd be easy to use for PID tuning values too. That's a good idea.
And I love the idea of a Prop doing the motor control. I've often thought about trying it, but I don't know enough about MOSFETs or protecting the Prop from the kick-back you need to sense to handle the timing. If you want any help with programming such a beast I'd love to be involved.
Ken - Got your email. In prep for the board, I don't suppose anyone can tell me which pins the HoverFly board uses for the ESCs, R/C connections, gyro, and accelerometer? If you have a schematic or document with it just point me at that.
Yep, I'm on it. Trying to round up a schematic right now. - Ken
I've got my hands full with the stuff I've got, so I'll wait for the new boards. My 9-channel remote does have additional analog controls, and they can be fed to any of the extra channels, or mixed with existing ones. I have one set to fine tune the throttle to help when hovering, but they'd be easy to use for PID tuning values too. That's a good idea.
Hey thats a nice feature. Guess that is what you get for a more expensive 9ch rc.
And I love the idea of a Prop doing the motor control. I've often thought about trying it, but I don't know enough about MOSFETs or protecting the Prop from the kick-back you need to sense to handle the timing. If you want any help with programming such a beast I'd love to be involved.
I have had this on the dwg board for some time. I have already seen code and understand the principles. The feedback loop is actually simple (a few resistors and cap IIRC). It is more an issue with pins - 6 control the 6 mosfets and 3 (or 4) for the feedback for each bldc motor. A few smarts have to be done with hardware to only use the props 30 pins while leaving 2 for comms. I have already found suitable Mosfets and drivers.
I will certainly let you know when I have the boards on the way as I would appreciate some help. I just do not have enough hours in the day for the projects I have on my plate.
By being able to measure the lift from each motor and prop combo (at first lift-off in hover mode) I think we could program the quad to do some interesting tricks in software Using a prop to control each motor and the multiple cogs at our disposal, some really fast responses could be done.
BTW I must search for that info on the Spektrum slave receiver protocols. This would save a lot of wiring and pins. This will be a bedtime exercise when I surf the net from my Xoom as I wind down for the day.
>>My rapid ascent problem is more likely one of balance or vibration resonance. If the weight isn't properly centered, applying full power to all the props may make it tip.<<
Are you Hit the maximum power output then ?
It result in no headroom for corections in the ESC's, and tip on the heavy side ?
LTech - I'm not sure. It doesn't feel like maximum throttle, and even if it was, my flight control code evenly increases throttle on one side while decreasing the other side, so at least the decrease should work to level it. It may be that my PID terms need adjustment for this case where there is less responsiveness. It's better now than it was before - it's easy to correct manually, but it feels like the software should handle it better.
Cluso - do you need to use all 6 pins to control the mosfets? There are only 3 phases, plus one pin for an "enable" that you could use or PWM. If each phase line selected the direction for that h-bridge, as long as you switched during the off side of the PWM you shouldn't have to worry about shorting. Does that make any sense? (and can that work?)
Jason: Yes there are ways to reduce the output pins but all then require the addition of logic to decode the states. This aplies to both the mosfet drivers and the feedback pins.
For the motors, each of the 3 pairs of mosfets in each phase requires the following sets of outputs... To describe the operation, I will use "1" for driving the P mosfet (+ side) and "0" for the N (gnd) and "X" for neither, for each half-bridge. Disregarding the overlap in switching, which can use the neither output, the following phases occur sequentially... 10X, X10, 01X, and XXX is none. Now you also need to permit reverse (ccw) if you do not want to change the wiring, so it requires X01, 01X, 1X0
For (analog) multiplexing the feedback, all that is required is to determine each X location as it is this wire that the feedback will be sensed from (i.e. the undriven motor wire)
However, for each of these cases, more logic has to be enlisted. That increases board size and cost and it soon becomes more sensible to use 4 cheap simple micros instead of the prop. But I really want to use a prop if at all possible.
Adding a 74x86 per motor (14pin) would do the job with some resistors but I can use a 14pin AVR for $1 more and no prop at all.
I just need to get my head around it again to see if I can find an alternative solution.
I thought it was possible to do it without using the X state at all - IE have PNP, PPN, and NPP states only. Connecting the positives together doesn't do anything, so there's no harm. That was my thinking at least - is this valid, or do you actually need the free-open state? (I can imagine you might need it for the feedback kick...)
So my thinking, based on the above, was that you'd have 3-pins to specify N or P for that H-bridge, and just use a NOT gate to set the output on the other FET, then have a single pin for enable for the whole thing that you'd use for PWM, and just be sure to switch the bridge state when it was disabled so you didn't short it during the transitions.
I fully realize my understanding of the problem isn't complete, so this might not be possible at all, I'm more asking if this can be done as simply as I think it can.
Hmmm... Re-reading your answer, I think I get it - you do need one side to be un-driven so you can detect the kickback. You could easily do a 3-motor one (TriCopter) and pair them for 6 (Hexa), or do a 4-motor version using two Props. Less cost effective, but a lot simpler to code. They could even use one EEPROM if you made one boot the other (though that doubles the startup time). Hmm... You could do a single 2-prop board for 6 motors, too... I want to make one that's a tri-shape using a pair of co-axial motors per arm. A single 6-motor board would be great for that, but not so good for quad or octo configs.
Would it be possible to use a diode and use the un-driven pins to read the kickback? IE, if you set the pin as an input, what does the MOSFET do in that case? Could you somehow multiplex the pins like that?
I like the idea of the Prop doing multiple motor control, but I certainly see the challenge in it.
I thought it was possible to do it without using the X state at all - IE have PNP, PPN, and NPP states only. Connecting the positives together doesn't do anything, so there's no harm. That was my thinking at least - is this valid, or do you actually need the free-open state? (I can imagine you might need it for the feedback kick...)
So my thinking, based on the above, was that you'd have 3-pins to specify N or P for that H-bridge, and just use a NOT gate to set the output on the other FET, then have a single pin for enable for the whole thing that you'd use for PWM, and just be sure to switch the bridge state when it was disabled so you didn't short it during the transitions.
I fully realize my understanding of the problem isn't complete, so this might not be possible at all, I'm more asking if this can be done as simply as I think it can. [/code]
No. You must have a small idle state between switching from P to N state or you will get a short across the power ground via the P & N mosfets. Also, only 2 wires are driven at a time. The third wire is the wire used for that section of the zero crossing feedback. And of course, you need to be able to reverse the direction in code for the 2 ccw motors unless you opt to set the motor wires swapped - which is what we do now, but its so much nicer in code.
[code]
Hmmm... Re-reading your answer, I think I get it - you do need one side to be un-driven so you can detect the kickback. You could easily do a 3-motor one (TriCopter) and pair them for 6 (Hexa), or do a 4-motor version using two Props. Less cost effective, but a lot simpler to code. They could even use one EEPROM if you made one boot the other (though that doubles the startup time). Hmm... You could do a single 2-prop board for 6 motors, too... I want to make one that's a tri-shape using a pair of co-axial motors per arm. A single 6-motor board would be great for that, but not so good for quad or octo configs.
Would it be possible to use a diode and use the un-driven pins to read the kickback? IE, if you set the pin as an input, what does the MOSFET do in that case? Could you somehow multiplex the pins like that?
I like the idea of the Prop doing multiple motor control, but I certainly see the challenge in it.
I am looking at all possible solutions. The mosfets need to be driven, particularly the P one because you need to switch the gate to +V to turn it off and close to gnd to turn it on. Otherwise you use an N channel, but then you have to derive a gate voltage above +v by up to 10V depending on the mosfet. So you must have a switcher to create the higher voltage and that comes with a space and parts cost too.
Unfortunately, the Quads have the most interest, so that lends itself to a quad board. 2x3 or 1x6 dual prop doesnt make any sense for Quad users.
I am also trying to have the pcb fit the existing 1.8"sq size model too because it fits those cheap Hammond boxes for protection. The Prop GPS board parallax have is 1.8x1.85" so this should also fit with a real squeeze.
The prop servo board I have underway was delayed for weeks because I was trying to squeeze the 4 sensors( gyro, accel, compass, press) all on the same pcb. In the end I gave up and decided to use a sensor pcb because I felt the sensor pcb could be used with other prop boards (or even non- prop boards in the hope they would transition to a prop later - just because its a better control chip than others being used). Also, I can use the Wii gyros & accels with my prop board too.
OOPS! Just realised I got this a little wrong. There are in fact 6 phases to drive a motor... using the P for +ve, L for -ve/gnd and X for no drive for each half bridge we have...
PxLLxP <--- motor wire A
xPPxLL <--- motor wire B
LLxPPx <--- motor wire C
Today we're kitting up 22 sets of ELEV-8s. I was able to get this shot from the Tech Support guys, as the first kits are built out of our regular production cycle as a more extensive QA/QC process.
Now we will issue kitting jobs to build the ELEV-8 Crash Pack! Sorry guys, if you don't have the guts to crash please stay on the porch. This kind of product takes a pretty solid set of assembly skills and electronic capability (soldering, some Propeller knowledge, some patience, etc.).
Comments
Almost all ESCs are "programmable/configurable" and people have figured out the protocols for this with some brands. It could be used to detect the ESCs and even configure them via code.
Here is a site with the info & code for Turnigy ESCs (the ones in the ELEV-8 kit are this brand): http://www.frank-zhao.com/cache/escprogrammingcardhack.php
I suspect that a number of them use the same protocol even, because people have mentioned being able to use programming cards from some brands with other brands.
Cluso99: that board setup looks decent. Some comments: You might want to consider making the mounting holes on the main board a little larger so you can put rubber grommets in it and then fit a screws thru them for mounting to help reduce vibrations (the hoverfly boards have this setup, see what I'm talking about in this image: http://static.rcgroups.net/forums/attachments/7/5/0/7/4/a4152448-124-IMG_4534.jpg ). Also, the sensor daughter board needs to be mounted solidly, I think you have those small holes at the opposite end from the connection header end that line up with the same size holes in the main board for this? Is the idea to solder in some posts?
Ken (and all) - I've updated the screen shots for my fully working QuadX Ground Station. The programming all works. I'll have to test the flight config (+ or x) by physically changing my quad temporarily, but it should all work. I'll also have to make sure that my pin choices are HoverFly compatible. The high-speed servo code is hard-wired (partially), but everything else I could configure easily in code.
I was thinking that you could use that protocol stuff to just detect if an ESC was present on the connector. Perhaps just do one of the commands to read the settings out (like the card does), and if it responds then you know an ESC is there. The Hoverfly boards do something to detect the presence of the ESCs and goes into an error state if one or more is missing.
I did another flight today with my latest changes. The fast ascent / descent wobble is still there, but it's reduced significantly. It used to wobble and oscillate badly during just about ANY descent, so this is a marked improvement.
By descending in place, you create a downward moving column of air that pulls you with it, and it's turbulent to boot. In a single-rotor heli, applying normal power may not overcome the downward speed of the air column, so you need more power just to stop the descent. In a multi-rotor, each rotor has the problem, and turbulence compounds it because they won't all see the same turbulence at the same time, making it more unstable than usual.
I call it "the descent sonic boom". :-) I was happy just to make the effect less pronounced.
My rapid ascent problem is more likely one of balance or vibration resonance. If the weight isn't properly centered, applying full power to all the props may make it tip. It should recover from that though, so I suspect it's the latter - higher motor speed hitting a resonant frequency of the gyro sensors and causing false tilt readings. I'll never know for sure unless I start recording my flight data to SD card.
It should be easy to rule out. If you add some weight and it gets worse then that would point to stalling - if it doesn't then it is something else.
To lighten the mood, HR manager was invited to record a crash for Nick on the whiteboard. Nick had at least 30 flights before this crash.
Let's hope for brighter days, and maybe that BMW will get parked on the other side of the building.
Ken Gracey
This code for the Atmega 328 only simulates the Turnigy programming card which cannot set the ESC upper and lower end points, at least my Turnigy card can't. Jason requires that the ESC upper and lower set points be established for his code to work correctly if I am not mistaken.
Regards,
TCIII
Ken - Got your email. In prep for the board, I don't suppose anyone can tell me which pins the HoverFly board uses for the ESCs, R/C connections, gyro, and accelerometer? If you have a schematic or document with it just point me at that.
The primary thing I was hoping for with the code was a way to detect if an ESC was connected or not. Being able to program it was secondary. Also, I'm sure with a logic analyzer and some time we could figure out the rest of the protocol to be able to set the upper and lower points and any other thing. If we get enough cards/ESC pairs to test with we could determine all the protocols. They all have to work over 1 signal wire, so it can't be terribly complex, and it's likely to be very similar for all of them.
Roy
I have a plain (passive - no prop) servo pcb ~1.8"x1.2" that has a 16pin servo header with series resistors and individual 5V jumpers. See my website for a pic (link in signature). PM me your address if you would like one (normally 10-14 days by post from Oz but its xmas so maybe longer ATM). Alternately, Ken may not be using the one I sent to him if you are close to him. I am also using my Prop BaseBoard1 that this plugs into. Forget if I sent one to Ken too. Anyway I can send you one too if you would like.
My new pcbs are in production but I will not see them here for 3-4 weeks (takes 2 weeks+ for the post)
I have wondered if it would be possible to easily modify the extra channels on the RC transmitter to send a varying pulse width rather than on/off, perhaps as simply just fitting a pot instead of the switch. That way, you could dynamically vary some of the PID values.
Great - I have a Spektrum DX6i so I have a satellite rx. Oh for the time to try it!
ESCs:
It is my intention to next design a tiny pcb to control 4 brushless motors with a prop. Two boards can be stacked for hex or octa copters. This way we will have total and fast responsive control of the motors (and feedback of motor revs for logging). However, this is little way off yet.
BTW this solves another problem too... that of power distribution. So the inclusion of the prop should not add any cost over separate cheap ESCs costs.
Thanks for the info Roy. I was aware of the vibration issue from the forums on other cpu solutions.
The mounting holes are 3mm but a 2mm screw and grommets could be used. However, the pcbs are designed to mount in a Hammond 1551R/S 2"sq box to protect it. The lid is underneath the pcb, with the main part of the box sandwiched on top of the pcb. The base of the main part of the box needs to have openings cut for the servo connections. This box may in turn be mounted with the appropriate grommets or whatever for the vibration issue. Perhaps double sided tape will also work - I am trying this on my existing pcbs.
The sensor daughter pcb is desiged, as you correctly determined, to have the other two pins on the other corners also soldered to the main pcb. While they can be in a socket, my preference is they be soldered. The 2 holes on the connector side are larger and will IIRC take 2mm screws for alternate mounting (perhaps they may be used with other pcbs).
I've got my hands full with the stuff I've got, so I'll wait for the new boards. My 9-channel remote does have additional analog controls, and they can be fed to any of the extra channels, or mixed with existing ones. I have one set to fine tune the throttle to help when hovering, but they'd be easy to use for PID tuning values too. That's a good idea.
And I love the idea of a Prop doing the motor control. I've often thought about trying it, but I don't know enough about MOSFETs or protecting the Prop from the kick-back you need to sense to handle the timing. If you want any help with programming such a beast I'd love to be involved.
Yep, I'm on it. Trying to round up a schematic right now. - Ken
I have had this on the dwg board for some time. I have already seen code and understand the principles. The feedback loop is actually simple (a few resistors and cap IIRC). It is more an issue with pins - 6 control the 6 mosfets and 3 (or 4) for the feedback for each bldc motor. A few smarts have to be done with hardware to only use the props 30 pins while leaving 2 for comms. I have already found suitable Mosfets and drivers.
I will certainly let you know when I have the boards on the way as I would appreciate some help. I just do not have enough hours in the day for the projects I have on my plate.
By being able to measure the lift from each motor and prop combo (at first lift-off in hover mode) I think we could program the quad to do some interesting tricks in software
BTW I must search for that info on the Spektrum slave receiver protocols. This would save a lot of wiring and pins. This will be a bedtime exercise when I surf the net from my Xoom as I wind down for the day.
>>My rapid ascent problem is more likely one of balance or vibration resonance. If the weight isn't properly centered, applying full power to all the props may make it tip.<<
Are you Hit the maximum power output then ?
It result in no headroom for corections in the ESC's, and tip on the heavy side ?
For the motors, each of the 3 pairs of mosfets in each phase requires the following sets of outputs... To describe the operation, I will use "1" for driving the P mosfet (+ side) and "0" for the N (gnd) and "X" for neither, for each half-bridge. Disregarding the overlap in switching, which can use the neither output, the following phases occur sequentially... 10X, X10, 01X, and XXX is none. Now you also need to permit reverse (ccw) if you do not want to change the wiring, so it requires X01, 01X, 1X0
For (analog) multiplexing the feedback, all that is required is to determine each X location as it is this wire that the feedback will be sensed from (i.e. the undriven motor wire)
However, for each of these cases, more logic has to be enlisted. That increases board size and cost and it soon becomes more sensible to use 4 cheap simple micros instead of the prop. But I really want to use a prop if at all possible.
Adding a 74x86 per motor (14pin) would do the job with some resistors but I can use a 14pin AVR for $1 more and no prop at all.
I just need to get my head around it again to see if I can find an alternative solution.
So my thinking, based on the above, was that you'd have 3-pins to specify N or P for that H-bridge, and just use a NOT gate to set the output on the other FET, then have a single pin for enable for the whole thing that you'd use for PWM, and just be sure to switch the bridge state when it was disabled so you didn't short it during the transitions.
I fully realize my understanding of the problem isn't complete, so this might not be possible at all, I'm more asking if this can be done as simply as I think it can.
Hmmm... Re-reading your answer, I think I get it - you do need one side to be un-driven so you can detect the kickback. You could easily do a 3-motor one (TriCopter) and pair them for 6 (Hexa), or do a 4-motor version using two Props. Less cost effective, but a lot simpler to code. They could even use one EEPROM if you made one boot the other (though that doubles the startup time). Hmm... You could do a single 2-prop board for 6 motors, too... I want to make one that's a tri-shape using a pair of co-axial motors per arm. A single 6-motor board would be great for that, but not so good for quad or octo configs.
Would it be possible to use a diode and use the un-driven pins to read the kickback? IE, if you set the pin as an input, what does the MOSFET do in that case? Could you somehow multiplex the pins like that?
I like the idea of the Prop doing multiple motor control, but I certainly see the challenge in it.
Unfortunately, the Quads have the most interest, so that lends itself to a quad board. 2x3 or 1x6 dual prop doesnt make any sense for Quad users.
I am also trying to have the pcb fit the existing 1.8"sq size model too because it fits those cheap Hammond boxes for protection. The Prop GPS board parallax have is 1.8x1.85" so this should also fit with a real squeeze.
The prop servo board I have underway was delayed for weeks because I was trying to squeeze the 4 sensors( gyro, accel, compass, press) all on the same pcb. In the end I gave up and decided to use a sensor pcb because I felt the sensor pcb could be used with other prop boards (or even non- prop boards in the hope they would transition to a prop later - just because its a better control chip than others being used). Also, I can use the Wii gyros & accels with my prop board too.
Hope this helps Jason.
PxLLxP <--- motor wire A
xPPxLL <--- motor wire B
LLxPPx <--- motor wire C
Now we will issue kitting jobs to build the ELEV-8 Crash Pack! Sorry guys, if you don't have the guts to crash please stay on the porch. This kind of product takes a pretty solid set of assembly skills and electronic capability (soldering, some Propeller knowledge, some patience, etc.).
Ken Gracey