]]>
Just to say i'm currently designing a uav daughtercard for the Parallella , along with ROS , mostly for Aircraft Recon projects
and gps Tracking , Heli's and the larger Quads , so more a top end design than budget .. , I'm debating a module plugin's approach, rather than all on one board .
which of course means if a sensor goes down your stuck , where with a module your only either missing that module for a while
and can switch that module off , if possible . but the rest is usable and for argument flyable , along with redundancy
as it's no good it going faulty at 800' ... and specific to this area so weight & size do play a large part , but without loosing functionality .
i have over 20 Years exp of GPS and Robotics R&D and an RC Gas Turbine Addict !
Dave
Statistics: Posted by cncbasher — Thu Jul 24, 2014 8:54 am
]]>
Fairly new into drones, but I have 2 up and working with the 32-bit ARM PixHawk that you're using, and another 2 with the 8-bit version of ArduPilot which I've tinkered a lot more with.
Question - have you tried OpenPilot?
From my (admittedly limited) experience so far, the 32-bit OpenPilot Revolution board seems to be surprisingly stable already, and code seems a little cleaner being C rather than C++
That said - I've not carried out a like for like comparison, and the frames I've tested the Ardupilot tend to be bigger with more cross sectional wind capture area than the frames I've tested the OP Revo on.
Anyway - let me know if you've got any repositories I can contribute to / test. I've got 4 Parallella 16-core boards to test with.
Cheers,
Dan.
Statistics: Posted by DanHouldsworth — Mon Jun 16, 2014 5:27 pm
]]>
Some differences from my earlier approach:
The system will have an integrated digi-mesh or xbee slot for communication with the outside world and a gps that outputs raw gps data.
This allows for multiple flight controllers and base-stations to create a RTK gps system, at a fraction of the cost of current systems.
The codebase will be based around ardupilot for pixhawk (arm-based), with some functions being offloaded on the fpga and epiphany.
The hardware will use the same sensors that are used in the pixhawk, for simplicity and not having to write so much interfacing code.
I think it's best to start out really simple, with a codebase that is already in a working state and optimize from there.
Statistics: Posted by Veqtor — Fri May 16, 2014 11:11 am
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
10 DOF IMU: Accelerometer + Gyroscope + Magnetometer + Barometer
http://www.uctronics.com/10dof-imu-ms56 ... p-857.html
also here:
http://www.ebay.com/itm/10DOF-IMU-MS561 ... 1031471551
Or this: http://www.drotek.fr/shop/en/home/62-im ... s5611.html
We only need to adopt this so it can be connected via the PMOD connections available in parallella.
Statistics: Posted by ali8 — Fri Jul 12, 2013 2:16 pm
]]>
Guys, you've already mentioned great and really needed components. Looking at what is commonly used by autopilot-community:
1) MPU 6050 [Accelerometer + Gyroscope]
2) HMC5883L-TR [Magnetometer]
3) MPXV5004DP [Abs. Pressure]
4) MPXH6115A6U[Pressure]]
5) MCP9700T-E/TT [[Temperature]
Items 1 & 2 are especially wide-spread and commonly used. For items 3,4 & 5 we can use any equivalents from other vendors, not a big deal, I think. The first two can be combined in a single MPU9050 but this is still new and not tested by the community (see the APM community autopilot).
I believe the above mentioned sensors (in a single daughter board) would be an essential complement to the parallella board.
==============
EDIT: There is a built in temp. sensor in the Zynq. Do we still need a stand alone temp. sensor?
Statistics: Posted by ali8 — Fri Jul 12, 2013 5:08 am
]]>
But yes, being able to offload part of the job, perhaps sensor-fusion incl gps and also saving some i/o for servos/escs by using an external board like the naze32/px4/autoquad could be a good idea. I just hope to be able establish a very fast movement vector-estimation by fusing rgbd optical flow with accels etc
I guess some reason to still consider a self-contained board is:
* Easy of use - someone who isn't into developing and experimenting could download a good software and just snap the parallella into the daughter-board, calibrate and be ready to go. Less parts means FC and sensor algorithms could be updated in one go.
* Less overlap of capabilities - The zynq fpga fabric should be able to replace most of the code in standard FCs without taking up any considerable space.
* Effectiveness - The only part of the parallella that would be occupied in a CV application would be the epiphany and part of the FPGA, wasting the resources provided by the dual core A9, which is in itself overkill for a FC-processor.
And also...
* Promotion - I want to support the parallella and as highly capable device it would be neat to show how it performs a task all by itself.
Statistics: Posted by Veqtor — Fri May 03, 2013 11:16 am
]]>