Thanks for all the feedback.... We will be meeting to go over the design soon, and I hope the next update can be posted in a week or so.
It is very interesting that some hardware ideas conflict with software ideas.... I'm always thinking about how I would code the firmware to help make the hardware design choices.... sometimes features that seem awesome could be difficult to code within the cogs available. Ultimately we want this to be an educational learning platform first, and so we must be able to deliver clear concise examples and documentation around the new flight controller.
I suppose squeezing all these features into such a small board size also imposes physical limitations.... It's certainly good to get your input on this balancing act!
Speaking of "balancing act", I might grab one of these boards and re-purpose it into my SideWay when they're available. Presumably it'll have access to more pins than the Hoverfly gimbal board I'm using now.
Speaking of "balancing act", I might grab one of these boards and re-purpose it into my SideWay when they're available. Presumably it'll have access to more pins than the Hoverfly gimbal board I'm using now.
Oh Yeah!
pins... if you don't need all 8 receive-channels, you could re-purpose any of those as control I/O's
and from the led hdr you could run an awesome light show too
The first run of boards for internal testing are in process. Here's the 3D render:
Significant edits since the schematic...
1. Added the xbee CTS/RTS
2. Aux port was moved next to the 4 esc's, and could be used as a 5th ESC out, (perhaps to control a gimbal), or to hook in a ping or some other distance sensor etc....
I guess we have the tough long wait now for parts and bare boards to arrive !!
Hopefully in couple weeks I can post some shots of the real thing coming out the oven! And then more importantly taking off!
1. Added the xbee CTS/RTS
2. Aux port was moved next to the 4 esc's, and could be used as a 5th ESC out, (perhaps to control a gimbal), or to hook in a ping or some other distance sensor etc....
Any comment on the feedback @JasonDorie and I gave?
Any comment on the feedback @JasonDorie and I gave?
Sure thing... On your points Cody:
(and please keep in mind that many of the design choices are based on educational and support......)
1. We don't want "stuff" hooking off the 3v3 line that might introduce noise/issues that could affect flight- that could be scary. Expansion boards should tap off the 5v or Lipos direct and use a local LDO. 5v is available at every receiver input and esc/aux output, so plenty of scope for customisation.
2. This remains a low priority, but might make the final release if initial tests suggest it could be useful- or if some example cases are provided that are good enough to sway "the decision makers" (In the layout, I did leave space for I2c headers next to the receiver ports, just in-case!...)
3. Considered, but not for this product.
4. Maybe bad, maybe GREAT! Were gonna try !
5&6. Conflicts with space/cost/etc.. aims, but we added the CTS/RTS back to the xbee header pins to provide essentially 4 I/Os, 3v3 and GND to that area. Were not really convinced of the need for CTS/RTS in this application (and not sleep modes either- no sleeping mid air!)... but it does open the chances for a small plugin gps board instead of the xbee (or as well as....)
7. Your probably right. We removed a couple already, and testing will prove the fate of the rest.
8. The xtal footprint is good for 5 or 6.25
9. For diagnostic leds that is not such an issue... not too concerned about brightness changing/ etc.... but anyway we added individual leds as space was available.
10. The newer FTDI part does not require (so I've been told).
11. The eeprom will be 64K, so you could roll your own bootloader and thus wirelessly program over xbee. This is not an objective for Parallax at the moment with this product, but it would be cool to see someone implement that.
"running out of cogs".... exactly!! We need to be realistic on features!
I think I already answered Jasons points too... We are more confident about the LED from our tests; we wanted SPI to give the comms cogs a bit more spare time to "do other stuff" (as you noted, cog time will be at a premium); and Jasons note about GPS is spot on. A future expansion board would probably want to include a 2nd propeller, GPS and maybe an SD-card for logging.
In any event, thanks again for all the feedback. You certainly helped get a couple ideas nudged up the design list
11. The eeprom will be 64K, so you could roll your own bootloader and thus wirelessly program over xbee. This is not an objective for Parallax at the moment with this product, but it would be cool to see someone implement that.
I think I already answered Jasons points too... We are more confident about the LED from our tests.
As a backup, I have verified that a WS2812B can be controlled from SPIN. I have one here and I made it cycle through a few colors with some clever code, so I'm less hesitant about it myself now.
Hot from the oven, here's a little treat for the weekend !!!
Yum Yum Yum !
(More news over the coming days - need time to sleep, then test !)
Before anyone spots them.... The headers will be right-angles on the finished product.... I only had straight headers on hand today
- Couldn't wait to get flying !!
That'll probably be decided by the "firmware master". Once he gets his hands on one of the prototypes it will fast become clear !!! We can fit either part of course.
I thought that I would add to the comments. I have bought a quadcopter, and have yet to invest some
time in it. I was always interested in the programming required to get the copter to fly. I have scanned
through the comments, but have not seen anyone comment on the actual contents of the software
required to fly the copter. It is interesting to me, to have a unit of learning to program a copters'
AI, (if I could use the term) to be able to understand the components of the "AI"s' flowchart
breakdown.
The new Parallax Flight Controller will be fully opensource. You will be able to access the hardware and SOFTWARE source code. Having had the fortune to watch that software grow, I can say that you will find it really well presented and clearly documented.
That will be a great resource for you to experiment and expand your knowledge with your quadcopter.
During August we are confident to have more solid news to report around this major new product. Currently we are "all hands to the propeller" in preparation for lauch !!
The next revision of the new Parallax Flight Controller has gone out for board manufacture, and we're hoping to get them into Parallax for manufacture mid-August.
This should be the final version, so once hardware tests are passed, then all eyes will be on the Software Guru to enable us to start shipping these out to customers!!!
Major changes:
a) Onboard 5v switching power-supply, which means we don't rely on the ESC (BEC) to power the flight controller. As there has been reliability issues with the ESC's, we felt it right to improve the Flight Controller with it's own reliable power system. The new Flight Controller is designed to connect directly to your battery packs- such as the Parallax 11.1V Elev-8 battery pack.
b) I2C headers added. Customer can connect any I2C compliant device, such as the SF10-A Laser Rangefinder
Thanks for the new pictures!
First impression, it looks like the Power and Ground are implemented at the ESC connections; or maybe just the ground.
I was just wondering if we have to cut the BEC Positive Connection on every ESC since power need not be supplied from there?
Interesting you should say that Jason.... I've not seen one either, but it was included in the "list of features and gotchas" !
For user flexibility on those headers, and also the aux headers, I ran the power traces just on the bottom of the board. So it would be possible/simple enough to cut those traces if power not required there.
But I will make a note to investigate the 5v @ esc option again. I believe Parallax was looking at all sorts of ESC options to replace the troublesome yellows, so this feature-option may have crept in as a result of that process.
For user flexibility on those headers, and also the aux headers, I ran the power traces just on the bottom of the board. So it would be possible/simple enough to cut those traces if power not required there.
Just add jumpers, most users will not cut traces.
IMHO.
the problem with jumpers, is they might "jump off" mid flight !!!
But yes your right Jim for long term.... Sorry, I was thinking in terms of the prototype & test users at this stage, whilst we figure out the final quirks.
And... the ESC question is certainly one of "the" quirks.... so many options to support.
That said, the layout as presented should be compatible with every ESC we've so far considered..... but testing still to be done, so I shouldn't count my rotor blades just yet!!
the problem with jumpers, is they might "jump off" mid flight !!!
But yes your right Jim for long term.... Sorry, I was thinking in terms of the prototype & test users at this stage, whilst we figure out the final quirks.
And... the ESC question is certainly one of "the" quirks.... so many options to support.
That said, the layout as presented should be compatible with every ESC we've so far considered..... but testing still to be done, so I shouldn't count my rotor blades just yet!!
Great point on the jumper coming off!
I have been talking with Kyle about ESC's. Got to find the "good ones".
Comments
It is very interesting that some hardware ideas conflict with software ideas.... I'm always thinking about how I would code the firmware to help make the hardware design choices.... sometimes features that seem awesome could be difficult to code within the cogs available. Ultimately we want this to be an educational learning platform first, and so we must be able to deliver clear concise examples and documentation around the new flight controller.
I suppose squeezing all these features into such a small board size also imposes physical limitations.... It's certainly good to get your input on this balancing act!
Oh Yeah!
pins... if you don't need all 8 receive-channels, you could re-purpose any of those as control I/O's
and from the led hdr you could run an awesome light show too
Glad you asked Jim.....
The first run of boards for internal testing are in process. Here's the 3D render:
Significant edits since the schematic...
1. Added the xbee CTS/RTS
2. Aux port was moved next to the 4 esc's, and could be used as a 5th ESC out, (perhaps to control a gimbal), or to hook in a ping or some other distance sensor etc....
I guess we have the tough long wait now for parts and bare boards to arrive !!
Hopefully in couple weeks I can post some shots of the real thing coming out the oven! And then more importantly taking off!
Any comment on the feedback @JasonDorie and I gave?
Sure thing... On your points Cody:
(and please keep in mind that many of the design choices are based on educational and support......)
1. We don't want "stuff" hooking off the 3v3 line that might introduce noise/issues that could affect flight- that could be scary. Expansion boards should tap off the 5v or Lipos direct and use a local LDO. 5v is available at every receiver input and esc/aux output, so plenty of scope for customisation.
2. This remains a low priority, but might make the final release if initial tests suggest it could be useful- or if some example cases are provided that are good enough to sway "the decision makers"
3. Considered, but not for this product.
4. Maybe bad, maybe GREAT! Were gonna try !
5&6. Conflicts with space/cost/etc.. aims, but we added the CTS/RTS back to the xbee header pins to provide essentially 4 I/Os, 3v3 and GND to that area. Were not really convinced of the need for CTS/RTS in this application (and not sleep modes either- no sleeping mid air!)... but it does open the chances for a small plugin gps board instead of the xbee (or as well as....)
7. Your probably right. We removed a couple already, and testing will prove the fate of the rest.
8. The xtal footprint is good for 5 or 6.25
9. For diagnostic leds that is not such an issue... not too concerned about brightness changing/ etc.... but anyway we added individual leds as space was available.
10. The newer FTDI part does not require (so I've been told).
11. The eeprom will be 64K, so you could roll your own bootloader and thus wirelessly program over xbee. This is not an objective for Parallax at the moment with this product, but it would be cool to see someone implement that.
"running out of cogs".... exactly!! We need to be realistic on features!
I think I already answered Jasons points too... We are more confident about the LED from our tests; we wanted SPI to give the comms cogs a bit more spare time to "do other stuff" (as you noted, cog time will be at a premium); and Jasons note about GPS is spot on. A future expansion board would probably want to include a 2nd propeller, GPS and maybe an SD-card for logging.
In any event, thanks again for all the feedback. You certainly helped get a couple ideas nudged up the design list
Way back in 2012 Martin_H figured out a nice cross-platform solution: http://forums.parallax.com/showthread.php/139534-Wireless-Programming-of-a-Propeller-chip-(video) It worked out well for me when I was programming a quadrotor. No lost fingers trying to stop a quad spinning out of control. Just a remote reset.
As a backup, I have verified that a WS2812B can be controlled from SPIN. I have one here and I made it cycle through a few colors with some clever code, so I'm less hesitant about it myself now.
J
Yum Yum Yum !
(More news over the coming days - need time to sleep, then test !)
Before anyone spots them.... The headers will be right-angles on the finished product.... I only had straight headers on hand today
- Couldn't wait to get flying !!
Question, the final version will have right angle headers, correct?
Are you going with the 6.25Mhz Xtal?
Jim
That'll probably be decided by the "firmware master". Once he gets his hands on one of the prototypes it will fast become clear !!! We can fit either part of course.
Any more juicy updates?
Any more juicy updates?
Why Yes Jim....but I've got to make you wait 36.254 hours... Can't be juicing out of season you know!
time in it. I was always interested in the programming required to get the copter to fly. I have scanned
through the comments, but have not seen anyone comment on the actual contents of the software
required to fly the copter. It is interesting to me, to have a unit of learning to program a copters'
AI, (if I could use the term) to be able to understand the components of the "AI"s' flowchart
breakdown.
The new Parallax Flight Controller will be fully opensource. You will be able to access the hardware and SOFTWARE source code. Having had the fortune to watch that software grow, I can say that you will find it really well presented and clearly documented.
That will be a great resource for you to experiment and expand your knowledge with your quadcopter.
During August we are confident to have more solid news to report around this major new product. Currently we are "all hands to the propeller" in preparation for lauch !!
The next revision of the new Parallax Flight Controller has gone out for board manufacture, and we're hoping to get them into Parallax for manufacture mid-August.
This should be the final version, so once hardware tests are passed, then all eyes will be on the Software Guru to enable us to start shipping these out to customers!!!
Major changes:
a) Onboard 5v switching power-supply, which means we don't rely on the ESC (BEC) to power the flight controller. As there has been reliability issues with the ESC's, we felt it right to improve the Flight Controller with it's own reliable power system. The new Flight Controller is designed to connect directly to your battery packs- such as the Parallax 11.1V Elev-8 battery pack.
b) I2C headers added. Customer can connect any I2C compliant device, such as the SF10-A Laser Rangefinder
So here are some images to enjoy!
First impression, it looks like the Power and Ground are implemented at the ESC connections; or maybe just the ground.
I was just wondering if we have to cut the BEC Positive Connection on every ESC since power need not be supplied from there?
5V is provided to the esc pins for those escs that require 5V logic level supply.
5V is provided to the esc pins for those escs that require 5V logic level supply.
Do those even exist? (not trying to be cheeky here, I've honestly never seen one and I'm wondering if you have)
Design looks good. I'm excited.
For user flexibility on those headers, and also the aux headers, I ran the power traces just on the bottom of the board. So it would be possible/simple enough to cut those traces if power not required there.
But I will make a note to investigate the 5v @ esc option again. I believe Parallax was looking at all sorts of ESC options to replace the troublesome yellows, so this feature-option may have crept in as a result of that process.
Just add jumpers, most users will not cut traces.
IMHO.
But yes your right Jim for long term.... Sorry, I was thinking in terms of the prototype & test users at this stage, whilst we figure out the final quirks.
And... the ESC question is certainly one of "the" quirks.... so many options to support.
That said, the layout as presented should be compatible with every ESC we've so far considered..... but testing still to be done, so I shouldn't count my rotor blades just yet!!
But yes your right Jim for long term.... Sorry, I was thinking in terms of the prototype & test users at this stage, whilst we figure out the final quirks.
And... the ESC question is certainly one of "the" quirks.... so many options to support.
That said, the layout as presented should be compatible with every ESC we've so far considered..... but testing still to be done, so I shouldn't count my rotor blades just yet!!
Great point on the jumper coming off!
I have been talking with Kyle about ESC's. Got to find the "good ones".
http://forums.parallax.com/discussion/163022/elev8-v3-announced