That's why Konstantin is busy with his canBLC: it is using the industrial can bus system, which is a lot more reliable. It's still in development, but I think his quad will fly in the next weeks with it.
I2C is a toy. If you want reliability take a bus designed with industrial strenght in mind.
I2c has not been designed with reliability and robustness in mind. it is primarily a simple protocol and basic hardware interface without galvanic isolation for interfacing Integrated Circuits on PCBs, not more.
@Chris: i am interested getting my hands on phonedrone board. Hoping to find some supplier in UK.
@Pete: I agree with you about having a brain ( as medic it makes sense). Your spinal cord acts as the bus, there is minimal logic that would work at spinal level( spinal reflexes) and each higher level has more and more functionality. But as it goes up the brain ( higher the functionality) the more time it takes. So the challenge could be to develop a cerebellum ( flight control board) a cortical ( visual recognition etc) and have a fast enough bus and some pwm/i2c interface to devices ( ESC etc).
@Chris Paulson, I agree with you. The original Ardu boards and UAV devboard will act like the core of the brain at the base of the human spine. They will deal with all the low level interrupts, gyros sampling, IMU style functions, and basic flying of the plane (Return to Landin if higher level computers fail). But other computers on the plane, are going to be doing higher level tasks. Things like "image recognition", "thermal navigation", "intelligent flight navigation past obstacles", "SLAM" etc are going to be easier to implement in a second computer where they already work today. That can be a pandboard, a beagle, or a gumstix. And the glue protocol is likely to be MAVLink. All of this has really already been done. It's just not been talked about much yet. The Phone Drone will have it's place too, but it does not have the literally tens of thousands of software packages and tools that come ready to use on a decent Linux implementation which will include a decent python environment. Example: Pixhawk ETH is using this type of architecture. I think that Tridge is using that architecture for the UAV Outback Challenge with Ardupilot and a Panda Board in his plane.
Chris: I agree, and perhaps this board will take off and provide that function. But in the meantime, we've bet on Android devices to do that and developed the PhoneDrone interface board as the bridge. It's hard to beat the smartphone industry in developing small, light and powerful computing platforms, and we all have old phones lying around waiting for such reuse. Today's pocket supercomputer is next year's outmoded model and a perfect candidate to put in a plane.
I'm surprised this didn't get more attention from this community. I see this type of processor as being critical to the Arduplane/Arducopter platforms in the fairly near future. This isn't a platform to replace the low-level control, but instead, supply a good platform to build an 'App' layer onto the Ardu* platforms.
With a properly written API, you could interface the Ardupilot to something like Python over a serial port. From there, the application development barrier is significantly reduced. I see big potential in navigation, sensing and scientific imaging. I'm excited by the fact that I could potentially take any off-the-shelf USB sensor dongle, plug it into the 'Ardubeagle', and map sensor values by lat/long and altitude. I could even imagine allowing some path planning control to loop back through a region where a sensor value was abnormally high or something.
I know power is a concern, but my board Beagle-XM runs at about 2.5W without a display. For a 30 minute flight, that's about 2% of a 4S 3000mAh battery capacity. It seems like an acceptable hit for the possibilities this platform provides.
Comments
That's why Konstantin is busy with his canBLC: it is using the industrial can bus system, which is a lot more reliable. It's still in development, but I think his quad will fly in the next weeks with it.
http://www.xkopter.de/en-us/entwicklung/canblc.aspx
Blog (only german,sorry): http://www.xkopter.de/en-us/entwicklung/canblc/canblcprojectblog.aspx
I2C is a toy. If you want reliability take a bus designed with industrial strenght in mind.
I2c has not been designed with reliability and robustness in mind. it is primarily a simple protocol and basic hardware interface without galvanic isolation for interfacing Integrated Circuits on PCBs, not more.
I would never use that on my frame for ESCs.
@basshead
PWM is unidirectional
with I2C you can get Informations from thes ESC's like powerconsumption or temperature.
You're right that I2C can produce some problem, but with a short busrecovery the communication will be reastablished.
I never had an I2C problem with my MK.
An other point is I2C and STM32F1xx . I think these guys will never bcome friends ;)
Great thing for a reasonable price.
I wonder what's the power consumption (idle, avg, max) with no IO devices attached?
What's the exact weight?
ps: just curious, why not Cortex A9?
@Chris: i am interested getting my hands on phonedrone board. Hoping to find some supplier in UK.
@Pete: I agree with you about having a brain ( as medic it makes sense). Your spinal cord acts as the bus, there is minimal logic that would work at spinal level( spinal reflexes) and each higher level has more and more functionality. But as it goes up the brain ( higher the functionality) the more time it takes. So the challenge could be to develop a cerebellum ( flight control board) a cortical ( visual recognition etc) and have a fast enough bus and some pwm/i2c interface to devices ( ESC etc).
@Chris Paulson, I agree with you. The original Ardu boards and UAV devboard will act like the core of the brain at the base of the human spine. They will deal with all the low level interrupts, gyros sampling, IMU style functions, and basic flying of the plane (Return to Landin if higher level computers fail). But other computers on the plane, are going to be doing higher level tasks. Things like "image recognition", "thermal navigation", "intelligent flight navigation past obstacles", "SLAM" etc are going to be easier to implement in a second computer where they already work today. That can be a pandboard, a beagle, or a gumstix. And the glue protocol is likely to be MAVLink. All of this has really already been done. It's just not been talked about much yet. The Phone Drone will have it's place too, but it does not have the literally tens of thousands of software packages and tools that come ready to use on a decent Linux implementation which will include a decent python environment. Example: Pixhawk ETH is using this type of architecture. I think that Tridge is using that architecture for the UAV Outback Challenge with Ardupilot and a Panda Board in his plane.
Chris: I agree, and perhaps this board will take off and provide that function. But in the meantime, we've bet on Android devices to do that and developed the PhoneDrone interface board as the bridge. It's hard to beat the smartphone industry in developing small, light and powerful computing platforms, and we all have old phones lying around waiting for such reuse. Today's pocket supercomputer is next year's outmoded model and a perfect candidate to put in a plane.
I'm surprised this didn't get more attention from this community. I see this type of processor as being critical to the Arduplane/Arducopter platforms in the fairly near future. This isn't a platform to replace the low-level control, but instead, supply a good platform to build an 'App' layer onto the Ardu* platforms.
With a properly written API, you could interface the Ardupilot to something like Python over a serial port. From there, the application development barrier is significantly reduced. I see big potential in navigation, sensing and scientific imaging. I'm excited by the fact that I could potentially take any off-the-shelf USB sensor dongle, plug it into the 'Ardubeagle', and map sensor values by lat/long and altitude. I could even imagine allowing some path planning control to loop back through a region where a sensor value was abnormally high or something.
I know power is a concern, but my board Beagle-XM runs at about 2.5W without a display. For a 30 minute flight, that's about 2% of a 4S 3000mAh battery capacity. It seems like an acceptable hit for the possibilities this platform provides.