Consider doing a bit of basic education on the state of regulation right now. Best practices and such are obviously part of the education. Add those things that would make people good ambassadors of the hobby as well as inform them where there are worry places. A little advocacy hints and tips might not be a bad thing. That backed with a basic understanding of where the friction lines are might do everybody a lot of good.
For an analogy, see the "hacking is good" type material, where it's framed as one's basic right to understand how the world they live in actually works. Done right, that kind of thing is hard to argue with and it promotes the general good. We are in a similar state of affairs with these devices where those kinds of basic messages are needed, IMHO of course.
Gees, I would have done it for free!!!! I need an excuse to go to Cali any how!!!! It is great to see that the new version seems to be a success thus far.
Consider doing a bit of basic education on the state of regulation right now.
Thanks Doug,
A complete tutorial of the current state of affairs with questions/answer is planned. We've discussed this topic quite a bit internally and think it's a required understanding for students before anything goes into the air. We're also requesting they take the modelaircraft.org free membership. - Ken
Gees, I would have done it for free!!!! I need an excuse to go to Cali any how!!!! It is great to see that the new version seems to be a success thus far.
I'd have done it for free as well!
When I was in California, I got the opportunity to see the new Elev-8 V2s and they're awesome. It was really cool to see what the Elev-8 V2 is capable of, such as high speed turns - or is it banks? - and carrying a robot.
I'm starting a STEM Engineering Program at Manitou Springs HS in Colorado. I would be very interested in some general feedback from any teachers who have purchased the ELEV 8 and are incorporating it into their program.
Here's a little insight as to what is going on within Parallax Engineering! We're beginning the design cycle for a Parallax produced quad-copter control board. We're calling it the Elev-8 Flight Control Board, or Elev-8 FC for short. Though the Elev-8 platform itself could use any flight control board on the market, Parallax originally partnered up with HoverFly Technologies to provide us with a Propeller based control board. The HoverFly Sport and Open boards feature some fantastic software defined control systems that give the Elev-8 great flight characteristics and easy installation for virtually any 5+ channel TX/RX combinations. As you know, education in engineering is a cornerstone of Parallax's existence and we plan on developing a UAV educational program. Such a program requires open access to all levels of the technology behind the curriculum, from PCB layout to software design to block diagrams. By designing our own flight control board, Parallax can align our education curriculum directly with the hardware and software design of the flight controller to ensure safety, ease of use, solid documentation, and perhaps most important metric - fun!
Though we are still in the early design phases, here's a peak into what we're looking to design:
- Parallax Propeller powered (of course )
- 9-DOF Invensense MPU-9250 Accelerometer/Gyro/Magnetometer sensor
- Altimeter
- XBee socket for real-time telemetry transmission and/or flight control
- #28509 PAM-7Q GPS Module header for GPS autonomous navigation
- Black box operation of the control board, with peripheral expansion header
- SD Card data logging
We have been working with a very talented and enthusiastic outside contractor named Michael Mulholland. Michael and I have been working together on a few other projects recently, which you all will see the results of very soon. With his awesome expertise and assistance, I know that the Elev-8 Flight Control board will be a hit.
Sounds interesting. Personally, I stay away from Invensense products (MPU-9250) since they're one of the most closed source and marketing based companies out there. I'd much rather use an LSM9DS1 from ST, or something from Analog.
In any case, with a project like this the hardware is the easy part. What do you have planned for software, and what's the scope?
If you haven't already, please also consider bringing out all pins, unused or otherwise, to a header row or socket, to allow easy hacking for cameras, lights, and other addons. You do mention a "peripheral expansion header" as part of black box operation, but it's not immediately clear how these go together, or what the peripheral expansion might entail.
I don't know anything about the Invensense line of products, but one thing to think about is allowing the ability for users to deploy something else. Your IMU can be onboard, but I think it would be helpful to jumper it so it can be brought out of service, and something else put in its place, if someone so desires. Certain IMUs, especially, seem to have a rabid following. If jumpers entail a vibration issue, would socketing a module work? Or using mini DIP switch?
A nice thing about the 9250 is that it can offload at least some of the processing for the IMU, whereas the ST part can't do that. I realize that's part of what makes them closed - they don't explain or even offer the code unless you NDA your life away apparently, but there are plenty of available implementations out there based on bus captures of the code upload. I'm not sure of the legality of that in a shipping product, but I think 3DRobotics is doing it.
Even then, I think the 9250 will only fuse the accelerometer and gyro data together, and it's still up to the implementer to orient and mix in the compass readings. 3DR mentioned in a blog post during development that it still saved them something like 40% of the work done in the IMU code.
Yep, the MPU-9250 IMU seems to run against the spirit of open source. It may be nicer to fab as an all-in-one chip solution, but Jason Dore understands the coding implications very well. Parallax might get held hostage to someone's greed.
Jason Dorie, Dave Hein, et al. have graciously provided working Propeller code for other 9DOF solutions. That seems a wiser way to go. See what is on the Hoverfly Gimbal Experimenters board.
The same 9DOF chipset as the HoverFly alternative on a tiny board is being sold on EBay for about $10USD. It might be more worthwhile to accommodate a 9DOF plug in of the end-user's choice than to build with the MPU-9250 soldered in place. Those that MUST have the MPU-9250 could swap out whatever is provided as a fully open-source item.
The fact that the MPU-9250 will only fuse 6DOF has been mentioned in many places. It isn't a true 9DOF by any means. So the Propeller would have to ignore the offloading and do the 9DOF mode entirely.
"So the Propeller would have to ignore the offloading"
Not quite true - It's possible to use the 6DOF solution provided by the on-board fusion and merge in the compass readings, which is how 3DR saved the 40% processing I referred to earlier.
I'm not sure how easily that will translate to the Prop though - Having to use Spin-based floats means quaternion math is going to be a little painful, and that's what the on board fusion code outputs. I have to start playing with code to see how fast that can be done in fixed point.
Well, the MPU-9250 IMU has always seemed more like a packaging solution and a complete design solution. The 9DOF claims are dubious or awkward at best.
I really enjoyed learning Madjwick via your code on a 9DOF alternative that is completely transparent.
Of course I am a bit concerned that NOT using the MPU-9250 might require two Propellers rather than one with the second being a dedicated IMU processor.
On the other hand, the magnetic compass reading are not quite as critical as the the fusing of the gyro and accelerometer. I suspect that at least one axis is not providing much data about the magnetic positioning. And just maybe, less frequent reading is okay. So having the code toggle between a 6DOF and 9DOF mode could be one way to work with the MPU-9250.
The MPU-9250 simply annoys me. I guess that is because it is a black box solution. Others might not care. And some certainly just want a black box and to make all the maths go away. (Those people just want to fly with the hottest performance for the cheapest price and free code.)
IMUs do use Quarternion math, but in a very limited fashion that works quite nicely. (It is all about tracking the rotation, and pretty much ignoring the concept of vectors with imaginary numbers.) But trying to extend my knowledge into other possible Quaternion uses has ended in confusion about having the i, j, and k imaginary numbers to deal with.
The Quaternion maths remain easy for rotation because the vectors are always at 1 and the square of 1 is 1 and the square root of 1 is 1.
So I suspect the likely best solution is to have an IMU plug-in that allows for choices. This is about sales volume, not about the purest open-source solution. And it is a compromise I wouldn't make for my personal design.
This allows it to process floats at full ASM speed (minus a few hub cycles), and in the background for the "calling" cog. Almost an async operation.
Some back of the envelope numbers:
Multiply takes ~550 instructions for the overhead and assume 25MIPS (@100MHz) per cog we get ~45,000 multiplies per second. Next, a quaternion multiply has 16 FP multiplies and 12 additions. Additions take ~150 instructions. That all puts us at ~1800 quaternion multiplications per second.
In the Madgwick IMU algorithm I count:
206 multiplications
4 divisions
85 subtractions
75 additions
That puts the output of the IMU running full cycle at 700 Hz in the worst case.
700Hz? From what was previously discussed, anything over 100Hz is more than enough. But the issues might be a shortage of Cogs or HubRAM space, not the iteration rate.
Hi all,
I have pretty much been advocating what is commonly available as the GY-85 board as an alternative to the MPU-9250.
But a bit of further investigation indicates my assertions may not be worthwhile.
1. The MPU-9250 can run in an alternative mode with using it's "black box". Just access the components via SPI
2. The MPU-9250 is all in one IC package that simplifies construction and positioning
3. The marketplace has complaints that the GY-85 boards being sold cheaply have a high proportion of failures.
And so, even those that want all open-source code for study can use the MPU-9250 in a different fashion. Nonetheless, the world of IMUs have added altimeters (and the FAA is restricting flights to below a certain altitude). The next generation of demand is going to be 10DOH devices. So offering a plug-in to accommodate the ever changing market might be wise.
Using SLRM's code as inspiration, I've got a non-Magwick, quaternion/DCM hybrid IMU running now, in ~76000 clock cycles, running on the HoverFly Gimbal experimenter board. It's not just about iteration rate - it's also about having time left over to do other work, like running the PID math, fusing in the compass or altimeter readings, and so on. 400Hz seems to be the agreed upon sweet spot, but I feel like a larger quad doesn't need it that quick. My last one ran at 250Hz and was rock solid.
@Jason Dorie
Happy to hear about this progress from you.
I had suspected as much.
Assuming that the Propeller provides adequate i/o pins, that seems to indicate that a one Propeller solution is possible. But I am sure that someone will always desire to add a lot of features and challenge the 28 i/o limit.
Happy New Year. I would love to see this code if you are willing to share.
Here's a sneak preview schematic for the new Parallax ELEV-8 Flight Controller.
You may have "heard some buzz" of this development..... We have been busy over the last few months working through various revisions of this design (this is the 3rd major one now), to accomodate various technology and supply issues, and to try and make this as user-fantastic as possible.
Now the design is ready (we hope!) and so felt it should be time to share!
Please post any questions or feedback - we would love to hear from you.
The flight controller (and later the expansion modules) will be at the core of the new Parallax UAV education program.
To deliver curriculum materials in an useful and engaging way, we want the entire design including the flight controller design and software examples to be open. This means that keeping certain aspects of the firmware/software closed is not an option for this product - however that would conflict with certain manufacturer supply agreements for certain sensors.
We really want students to have the opportunity to learn everything about flight control (including the complex math you are famous for on these forums!), not just how to build the thing and operate the remote control.
And so the flight controller sensor choices were made so that we might really deliver the "education" in engineering !
Yes, xbee for telemetry, and maybe one day for flight control.
The motor outputs are limited to 4 in this revision - that was a design choice based somewhat on sales and support experience at Parallax. We also did not want to delay this product with too many "future" options and variables - just keep it simple (almost!)... That's kinda tough for such a product!
On the channel inputs.... 8 matches nicely with 8-ch receivers!
Seriously, I already use 5 for basic control, 1 for video control, 1 for lights and can imagine a whole range of exciting things to toggle with the last ch. I could even dream of needing more, or perhaps using an xbee protocol instead. Of course, free-time (or lack of) keeps my channel count low!!
Your absolutely right about the software - where all the magic will happen. We have included the onboard usb programming port to encourage experiment and development of the software, as I'm sure we will be eager to ship the product as early as possible with a simple control firmware installed.
All very exciting, and I will keep this thread updated over the coming weeks.
My hoverfly open died when an esc let out the magic smoke. A new FC from Parallax is good news. Have any idea on price and availability yet?
-dan
If you're looking for something to "hold you over', you could give the CC3D board a try. Hobby King carries them as well as some other distributors. For around $40 you can get a decent flight controller that just "drops in". It has both an accelerometer and a gyro, so you can have both a "rate" and an "attitude" mode.
The design and software comes from the OpenPilot project. They have a nice web site, wiki and forum. However, the forum can be unfriendly at times. Reminds me of the Soup Nazi skits on Seinfeld. Ask nicely and correctly or get shown the door.
Anyway, I'm flying with one now and it's great. The groundstation software exposes a lot of tuning options, which can be a little daunting. I also found that all motor rotations for this controller are opposite of the HoverFly Open. Fortunately, one check box handles the change easily.
I still have my HoverFly Open and plan to use it again, either on this quad or maybe another one.
I'm also interested in the new upcoming Parallax flight controller. Looks like it will support other sensors and capabilities over the Open and the CC3D.
The board seems like a good start, but I think it's missing some important aspects.
The main issue with the schematic is that it's very hard wired. There is little room for expansion or experimentation. What I would like to see:
1. Power headers (3.3v, 5v, VIN) to allow powering peripheral devices. The more headers (and formats) the merrier.
2. Pin breakouts for the I2C bus
3. The option to jump around the various cleaver bits on the expansion serial bus, aux header, and the radio receiver inputs in order to get to the Prop I/O pin directly.
4. Using the WS2812B for an LED indicator seems like a bad idea. LED indicators are supposed to be simple, and the WS2812B is anything but. I'd rather just have a single color LED on the I/O pin, then a header to add a WS2812B string if the user wants to.
5. An explicit, 2 way (RX/TX) connector for a GPS would be a good idea (eg, a U-Blox M8)
6. Likewise, breaking out the XBee RX/TX into a 4 pin 0.1 header would allow for other radios to be used (eg, a 3DR radio)
7. I'm skeptical of the need for putting the LSM9DS1 and the LPS22HB on SPI (vs I2C). I really don't think all of the extra pins (interupt, DRDY, etc.) need to be connected at all. The Propeller is perfectly suited for polling.
8. I hope you're planning on using a 6.25MHz crystal for the Propeller.
9. The FT231XQ should have a resistor for each LED on the CBUS1 and CBUS2 pins as shown on page 31 in the datasheet. The same principle holds for the XBee LEDs.
10. The better Propeller boards have a buffer circuit on the USB RX/TX to prevent resets to the Propeller, which I don't see here.
11. What about wireless programming? When I was working on my Propeller quad design, wireless programming (via Wixels) was both a productivity booster and a safety consideration. I was able to quickly and safely stop a running program, update code, and retry all without leaving my computer.
Personally, I like the choice of the LSM9DS1.
What's the software layout that this board is supposed to fulfill? I'd be worried about running out of cogs, especially for an autonomous operation.
Here's a sneak preview schematic for the new Parallax ELEV-8 Flight Controller.
You may have "heard some buzz" of this development..... We have been busy over the last few months working through various revisions of this design (this is the 3rd major one now), to accomodate various technology and supply issues, and to try and make this as user-fantastic as possible.
Now the design is ready (we hope!) and so felt it should be time to share!
Please post any questions or feedback - we would love to hear from you.
Hey Von thanks for sharing!! What an exciting project!!
Have you thought about adding flow control to your xBee connection? If you have the pins available on your Prop you may want to think about it. Not sure what xBee your are planning on using but if it is one that supports sleep mode they can be setup to use flow control to wake-up the propeller. Say you want to put the system on standby and then wake it up to run an automated flight plan. The xBee ZB SMT would be perfect for that if it was in sleep mode and had its CTS pin tied to one of the propeller's pins. The xBee will pull CTS low when it wants to send data to the prop. So you could put the propeller asleep and just wait for a pin to go low. If you want to give the propeller the ability to wake-up the xBee you can use the On/Sleep pin.
Looking forward to seeing more on this controller!!
Hey Von thanks for sharing!! What an exciting project!!
Have you thought about adding flow control to your xBee connection? If you have the pins available on your Prop you may want to think about it. Not sure what xBee your are planning on using but if it is one that supports sleep mode they can be setup to use flow control to wake-up the propeller. Say you want to put the system on standby and then wake it up to run an automated flight plan. The xBee ZB SMT would be perfect for that if it was in sleep mode and had its CTS pin tied to one of the propeller's pins. The xBee will pull CTS low when it wants to send data to the prop. So you could put the propeller asleep and just wait for a pin to go low. If you want to give the propeller the ability to wake-up the xBee you can use the On/Sleep pin.
Looking forward to seeing more on this controller!!
Interesting idea. You could do something similar without an extra pin by putting at WAITPNE on the RX line, and waiting for the start bit. Of course you'd have to make sure to have a serial routine running to capture all the characters, so that's one cog active in "sleep" mode.
I think the problem with the WS2812 is going to be talking to it in Spin. In Spin, the smallest waitcnt() you can reliably do is 381 clocks, because of overhead in the interpreter.
The shortest bit-time in the WS2812 protocol is 0.35uS, with a 150ns tolerance. If my math is right, that's 28 clocks on an 80MHz Prop. Easy in PASM, but impossible in Spin, so that's potentially a COG gone right there unless you wedge the driver for it into one of the other PASM cogs.
I like the RGB LED on the Hoverfly boards. It's trivial to make it go, and digital color mixing gives you 8 possible choices (including off), which is great for status indication.
SPI allows for higher data rates, which opens up the possibility to connect more peripherals to the same COG, but it takes more pins, and means a CS line per device. Like SLRM, I would also skip the interrupt lines and just do polling.
Having 4 R/C outputs seems limiting, especially if you want to aim a camera gimbal. I suppose you could just pull the lines directly off the receiver, but it seems like such a simple thing to add.
It won't be possible to do autonomous flight on this board without another Prop. You'd need a GPS to hold position anyway, so any add-on GPS board could just include the additional Prop to make up the required horsepower. I would've liked to see that on this board though - Doing the math for the sensor fusion is hard, and adding the altimeter is going to make it challenging to fit into a single Prop. I'd be very surprised if there were resources left over for user code.
Comments
For an analogy, see the "hacking is good" type material, where it's framed as one's basic right to understand how the world they live in actually works. Done right, that kind of thing is hard to argue with and it promotes the general good. We are in a similar state of affairs with these devices where those kinds of basic messages are needed, IMHO of course.
Thanks Doug,
A complete tutorial of the current state of affairs with questions/answer is planned. We've discussed this topic quite a bit internally and think it's a required understanding for students before anything goes into the air. We're also requesting they take the modelaircraft.org free membership. - Ken
I'd have done it for free as well!
When I was in California, I got the opportunity to see the new Elev-8 V2s and they're awesome. It was really cool to see what the Elev-8 V2 is capable of, such as high speed turns - or is it banks? - and carrying a robot.
John Ryan, Manitou Springs HS, CO
jryan@mssd14.org
-MattG
Here's a little insight as to what is going on within Parallax Engineering! We're beginning the design cycle for a Parallax produced quad-copter control board. We're calling it the Elev-8 Flight Control Board, or Elev-8 FC for short. Though the Elev-8 platform itself could use any flight control board on the market, Parallax originally partnered up with HoverFly Technologies to provide us with a Propeller based control board. The HoverFly Sport and Open boards feature some fantastic software defined control systems that give the Elev-8 great flight characteristics and easy installation for virtually any 5+ channel TX/RX combinations. As you know, education in engineering is a cornerstone of Parallax's existence and we plan on developing a UAV educational program. Such a program requires open access to all levels of the technology behind the curriculum, from PCB layout to software design to block diagrams. By designing our own flight control board, Parallax can align our education curriculum directly with the hardware and software design of the flight controller to ensure safety, ease of use, solid documentation, and perhaps most important metric - fun!
Though we are still in the early design phases, here's a peak into what we're looking to design:
- Parallax Propeller powered (of course
- 9-DOF Invensense MPU-9250 Accelerometer/Gyro/Magnetometer sensor
- Altimeter
- XBee socket for real-time telemetry transmission and/or flight control
- #28509 PAM-7Q GPS Module header for GPS autonomous navigation
- Black box operation of the control board, with peripheral expansion header
- SD Card data logging
We have been working with a very talented and enthusiastic outside contractor named Michael Mulholland. Michael and I have been working together on a few other projects recently, which you all will see the results of very soon. With his awesome expertise and assistance, I know that the Elev-8 Flight Control board will be a hit.
Cheers,
Daniel
In any case, with a project like this the hardware is the easy part. What do you have planned for software, and what's the scope?
If you haven't already, please also consider bringing out all pins, unused or otherwise, to a header row or socket, to allow easy hacking for cameras, lights, and other addons. You do mention a "peripheral expansion header" as part of black box operation, but it's not immediately clear how these go together, or what the peripheral expansion might entail.
I don't know anything about the Invensense line of products, but one thing to think about is allowing the ability for users to deploy something else. Your IMU can be onboard, but I think it would be helpful to jumper it so it can be brought out of service, and something else put in its place, if someone so desires. Certain IMUs, especially, seem to have a rabid following. If jumpers entail a vibration issue, would socketing a module work? Or using mini DIP switch?
Even then, I think the 9250 will only fuse the accelerometer and gyro data together, and it's still up to the implementer to orient and mix in the compass readings. 3DR mentioned in a blog post during development that it still saved them something like 40% of the work done in the IMU code.
Jason Dorie, Dave Hein, et al. have graciously provided working Propeller code for other 9DOF solutions. That seems a wiser way to go. See what is on the Hoverfly Gimbal Experimenters board.
The same 9DOF chipset as the HoverFly alternative on a tiny board is being sold on EBay for about $10USD. It might be more worthwhile to accommodate a 9DOF plug in of the end-user's choice than to build with the MPU-9250 soldered in place. Those that MUST have the MPU-9250 could swap out whatever is provided as a fully open-source item.
The fact that the MPU-9250 will only fuse 6DOF has been mentioned in many places. It isn't a true 9DOF by any means. So the Propeller would have to ignore the offloading and do the 9DOF mode entirely.
Not quite true - It's possible to use the 6DOF solution provided by the on-board fusion and merge in the compass readings, which is how 3DR saved the 40% processing I referred to earlier.
I'm not sure how easily that will translate to the Prop though - Having to use Spin-based floats means quaternion math is going to be a little painful, and that's what the on board fusion code outputs. I have to start playing with code to see how fast that can be done in fixed point.
I really enjoyed learning Madjwick via your code on a 9DOF alternative that is completely transparent.
Of course I am a bit concerned that NOT using the MPU-9250 might require two Propellers rather than one with the second being a dedicated IMU processor.
On the other hand, the magnetic compass reading are not quite as critical as the the fusing of the gyro and accelerometer. I suspect that at least one axis is not providing much data about the magnetic positioning. And just maybe, less frequent reading is okay. So having the code toggle between a 6DOF and 9DOF mode could be one way to work with the MPU-9250.
The MPU-9250 simply annoys me. I guess that is because it is a black box solution. Others might not care. And some certainly just want a black box and to make all the maths go away. (Those people just want to fly with the hottest performance for the cheapest price and free code.)
IMUs do use Quarternion math, but in a very limited fashion that works quite nicely. (It is all about tracking the rotation, and pretty much ignoring the concept of vectors with imaginary numbers.) But trying to extend my knowledge into other possible Quaternion uses has ended in confusion about having the i, j, and k imaginary numbers to deal with.
The Quaternion maths remain easy for rotation because the vectors are always at 1 and the square of 1 is 1 and the square root of 1 is 1.
So I suspect the likely best solution is to have an IMU plug-in that allows for choices. This is about sales volume, not about the purest open-source solution. And it is a compromise I wouldn't make for my personal design.
For example, this spin code does a few quat multiplies and some other math:
https://code.google.com/p/anzhelka/source/browse/software/spin/src/block_moment.spin#144
It's then run through a pre-processor and turned into this:
https://code.google.com/p/anzhelka/source/browse/software/spin/src/block_moment_output.spin#197
And is fed on command to a modified version of F32 that takes an instruction sequence base address:
https://code.google.com/p/anzhelka/source/browse/software/spin/lib/F32_CMD.spin
This allows it to process floats at full ASM speed (minus a few hub cycles), and in the background for the "calling" cog. Almost an async operation.
Some back of the envelope numbers:
Multiply takes ~550 instructions for the overhead and assume 25MIPS (@100MHz) per cog we get ~45,000 multiplies per second. Next, a quaternion multiply has 16 FP multiplies and 12 additions. Additions take ~150 instructions. That all puts us at ~1800 quaternion multiplications per second.
In the Madgwick IMU algorithm I count:
206 multiplications
4 divisions
85 subtractions
75 additions
That puts the output of the IMU running full cycle at 700 Hz in the worst case.
I have pretty much been advocating what is commonly available as the GY-85 board as an alternative to the MPU-9250.
But a bit of further investigation indicates my assertions may not be worthwhile.
1. The MPU-9250 can run in an alternative mode with using it's "black box". Just access the components via SPI
2. The MPU-9250 is all in one IC package that simplifies construction and positioning
3. The marketplace has complaints that the GY-85 boards being sold cheaply have a high proportion of failures.
And so, even those that want all open-source code for study can use the MPU-9250 in a different fashion. Nonetheless, the world of IMUs have added altimeters (and the FAA is restricting flights to below a certain altitude). The next generation of demand is going to be 10DOH devices. So offering a plug-in to accommodate the ever changing market might be wise.
Happy to hear about this progress from you.
I had suspected as much.
Assuming that the Propeller provides adequate i/o pins, that seems to indicate that a one Propeller solution is possible. But I am sure that someone will always desire to add a lot of features and challenge the 28 i/o limit.
Happy New Year. I would love to see this code if you are willing to share.
Here's a sneak preview schematic for the new Parallax ELEV-8 Flight Controller.
You may have "heard some buzz" of this development..... We have been busy over the last few months working through various revisions of this design (this is the 3rd major one now), to accomodate various technology and supply issues, and to try and make this as user-fantastic as possible.
Now the design is ready (we hope!) and so felt it should be time to share!
Please post any questions or feedback - we would love to hear from you.
Michael.
Schematic_ELEV8FC_20150327_PRERELEASE.pdf
Will be watching w/interest. The software will be the key, both onboard and the config / ground software.
-Russ
In a word, Openness.
The flight controller (and later the expansion modules) will be at the core of the new Parallax UAV education program.
To deliver curriculum materials in an useful and engaging way, we want the entire design including the flight controller design and software examples to be open. This means that keeping certain aspects of the firmware/software closed is not an option for this product - however that would conflict with certain manufacturer supply agreements for certain sensors.
We really want students to have the opportunity to learn everything about flight control (including the complex math you are famous for on these forums!), not just how to build the thing and operate the remote control.
And so the flight controller sensor choices were made so that we might really deliver the "education" in engineering !
Yes, xbee for telemetry, and maybe one day for flight control.
The motor outputs are limited to 4 in this revision - that was a design choice based somewhat on sales and support experience at Parallax. We also did not want to delay this product with too many "future" options and variables - just keep it simple (almost!)... That's kinda tough for such a product!
On the channel inputs.... 8 matches nicely with 8-ch receivers!
Seriously, I already use 5 for basic control, 1 for video control, 1 for lights and can imagine a whole range of exciting things to toggle with the last ch. I could even dream of needing more, or perhaps using an xbee protocol instead. Of course, free-time (or lack of) keeps my channel count low!!
Your absolutely right about the software - where all the magic will happen. We have included the onboard usb programming port to encourage experiment and development of the software, as I'm sure we will be eager to ship the product as early as possible with a simple control firmware installed.
All very exciting, and I will keep this thread updated over the coming weeks.
Michael.
-dan
Their license prohibited us from sharing our source code, which puts us back in the situation where we are today.
Ken Gracey
If you're looking for something to "hold you over', you could give the CC3D board a try. Hobby King carries them as well as some other distributors. For around $40 you can get a decent flight controller that just "drops in". It has both an accelerometer and a gyro, so you can have both a "rate" and an "attitude" mode.
The design and software comes from the OpenPilot project. They have a nice web site, wiki and forum. However, the forum can be unfriendly at times. Reminds me of the Soup Nazi skits on Seinfeld. Ask nicely and correctly or get shown the door.
Anyway, I'm flying with one now and it's great. The groundstation software exposes a lot of tuning options, which can be a little daunting. I also found that all motor rotations for this controller are opposite of the HoverFly Open. Fortunately, one check box handles the change easily.
I still have my HoverFly Open and plan to use it again, either on this quad or maybe another one.
I'm also interested in the new upcoming Parallax flight controller. Looks like it will support other sensors and capabilities over the Open and the CC3D.
-Russ
The board seems like a good start, but I think it's missing some important aspects.
The main issue with the schematic is that it's very hard wired. There is little room for expansion or experimentation. What I would like to see:
1. Power headers (3.3v, 5v, VIN) to allow powering peripheral devices. The more headers (and formats) the merrier.
2. Pin breakouts for the I2C bus
3. The option to jump around the various cleaver bits on the expansion serial bus, aux header, and the radio receiver inputs in order to get to the Prop I/O pin directly.
4. Using the WS2812B for an LED indicator seems like a bad idea. LED indicators are supposed to be simple, and the WS2812B is anything but. I'd rather just have a single color LED on the I/O pin, then a header to add a WS2812B string if the user wants to.
5. An explicit, 2 way (RX/TX) connector for a GPS would be a good idea (eg, a U-Blox M8)
6. Likewise, breaking out the XBee RX/TX into a 4 pin 0.1 header would allow for other radios to be used (eg, a 3DR radio)
7. I'm skeptical of the need for putting the LSM9DS1 and the LPS22HB on SPI (vs I2C). I really don't think all of the extra pins (interupt, DRDY, etc.) need to be connected at all. The Propeller is perfectly suited for polling.
8. I hope you're planning on using a 6.25MHz crystal for the Propeller.
9. The FT231XQ should have a resistor for each LED on the CBUS1 and CBUS2 pins as shown on page 31 in the datasheet. The same principle holds for the XBee LEDs.
10. The better Propeller boards have a buffer circuit on the USB RX/TX to prevent resets to the Propeller, which I don't see here.
11. What about wireless programming? When I was working on my Propeller quad design, wireless programming (via Wixels) was both a productivity booster and a safety consideration. I was able to quickly and safely stop a running program, update code, and retry all without leaving my computer.
Personally, I like the choice of the LSM9DS1.
What's the software layout that this board is supposed to fulfill? I'd be worried about running out of cogs, especially for an autonomous operation.
Hey Von thanks for sharing!! What an exciting project!!
Have you thought about adding flow control to your xBee connection? If you have the pins available on your Prop you may want to think about it. Not sure what xBee your are planning on using but if it is one that supports sleep mode they can be setup to use flow control to wake-up the propeller. Say you want to put the system on standby and then wake it up to run an automated flight plan. The xBee ZB SMT would be perfect for that if it was in sleep mode and had its CTS pin tied to one of the propeller's pins. The xBee will pull CTS low when it wants to send data to the prop. So you could put the propeller asleep and just wait for a pin to go low. If you want to give the propeller the ability to wake-up the xBee you can use the On/Sleep pin.
Looking forward to seeing more on this controller!!
Interesting idea. You could do something similar without an extra pin by putting at WAITPNE on the RX line, and waiting for the start bit. Of course you'd have to make sure to have a serial routine running to capture all the characters, so that's one cog active in "sleep" mode.
The shortest bit-time in the WS2812 protocol is 0.35uS, with a 150ns tolerance. If my math is right, that's 28 clocks on an 80MHz Prop. Easy in PASM, but impossible in Spin, so that's potentially a COG gone right there unless you wedge the driver for it into one of the other PASM cogs.
http://www.world-semi.com/uploads/soft/130222/1-130222154S6.pdf
I like the RGB LED on the Hoverfly boards. It's trivial to make it go, and digital color mixing gives you 8 possible choices (including off), which is great for status indication.
SPI allows for higher data rates, which opens up the possibility to connect more peripherals to the same COG, but it takes more pins, and means a CS line per device. Like SLRM, I would also skip the interrupt lines and just do polling.
Having 4 R/C outputs seems limiting, especially if you want to aim a camera gimbal. I suppose you could just pull the lines directly off the receiver, but it seems like such a simple thing to add.
It won't be possible to do autonomous flight on this board without another Prop. You'd need a GPS to hold position anyway, so any add-on GPS board could just include the additional Prop to make up the required horsepower. I would've liked to see that on this board though - Doing the math for the sensor fusion is hard, and adding the altimeter is going to make it challenging to fit into a single Prop. I'd be very surprised if there were resources left over for user code.