Parallella Flight Controller / Robot / UAV Daughter Board

[tintin]

Would this one work? 3 days to go.

http://www.kickstarter.com/projects/110 ... for-your-p

[Veqtor]

Even if you're making a rover or a robot, having a IMU is going to be highly useful. So some kind of IMU is essential. I also believe that sticking with the widely established 40mm square hole mounting standard is a very good idea. Unfortunatly, most ESCs, servos and RC receivers only speak 5v, which is a bummer because otherwise the bidirectionality of the FPGA IO could be used to allow for many different IO configurations. But I think sticking with a strictly CPPM and SBUS system is the way to go in terms of input. Most RXs that you should be using have this system. Also, using an XBEE for control is a very good idea, as is having several UART-type ports for connecting GPS's, OSD's, 3DR telemetry, etc etc.

Having had quite a bit of experience with both AVR based and ARM cortex mX based FCs, I still think making a TRULY autonomous vehicle with the parallella for its brain is a good idea. In an ideal configuration with GPS, XBEE Pro 2b and long range video, it could outperform current offerings significantly. The Epiphany chip lends itself really well for optical flow based positioning, image recognition and of course all the heavy matrix multiplications involved in sensor processing such as that performed by the autoquad system.

I also think its a good idea when considering power consumption, pushing an m-series arm to its limits for real-time math, adding stuff like an RPi to process kinect depth data is hardly ideal in terms of weight and effiency.

Because of this I've decided to go along with this project, but my biggest dilemma is deciding between using the MPU9150 or going for individual sensors that lack any kind of internal processing. Doing all the sensor fusion on the fpga fabric and on the EP, might give us better results but IT WILL take a hell of a lot more work to get it work acceptably and even more so to get it the point where AQ is now.

I'm also unsure as to where to go forward with the depth sensing stuff, as it appears now the capri sensor from primesense won't work for outdoor applications.

Thoughts?

[ESI]

Hi there,
I am thinking of a daughter card with some imu sensors on it (currently thinking of 3axisG plus 3axis Magneto from ST and 3axis Gyro aslo ST). Adding a ADC (maybe with SPI interface) and some drivers to to connect to servos. Interfacing serial interface for GPS, and a pressure sensor. I would also need to interface BLDC controllers for the motors. This should be enough to have a flight controller. If there are still pins from FPGA free, I am thinking raw camera interface(s) (8bit data plus I2C) for more sensor fusion, and giving the epiphany chip something to work. Additional SPIs for RFM12 e.g. would not hurt either. The daughter card get it power from the LiPo accumulator (11 or 15v) and needs to generated the voltages needed by parallella.

The daughter card would only cover the FPGA connector and the power connector. The other connectors would be free, if you need more epiphany to cluster.

FPGA:
I would at I2C master and SPI masters to read the sensors continuesly and just readout the last values from FPGA register within the Zynq. Aso communcaition to BLDC and receiver would be FPGA based. The controller software just has a memory interfaces to the sensors and actuators. Also the picture of the camera would be read out by the FPGA.

Software:
I would patch a Kernel with Xenomai for the cortex-A9 (has been done for Pandaboard..) and port OpenPilot to the Xenomai realtime domain.
For logging, cominication and maybe higher level navigation or other funtions I would use Linux-user space. The Epiphany would help with video and sensor fusion, or whatever numbercrunching comes up.


So we would have full Linux on cortex-A9, but realtime control in the Xenomai domain. The Epiphany could support both Linux and Flightcontroller.

This could be a base for many applications, the IMU-Sensor on board do not hurt, so you have an board wo connect some SPI, some I2C, also output drivers (servo)....
For multicoprt, this would be a very powerful (maybe too powerful) platform, I guess.
just an idea....
any thoughts?
BR
Joerg

[Gravis]

[Veqtor]

Done some more progress researching this.
Looking now for someone who can route some high speed boards.

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.

[DanHouldsworth]

Veqtor - I'm interested in helping out on this.

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.

[cncbasher]

Hi All ,

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

[Grumpy Old Coot]

Freescale has some really interesting parts. If you speak "Coldfire V1" and have a copy of CodeWarrior (or similar), the FXLC95000CL functions as an intelligent sensor/sensor hub.