Parallella Flight Controller / Robot / UAV Daughter Board

Sub forum for Parallella daughter cards and accessories

Moderator: Folknology

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby tintin » Mon Aug 05, 2013 3:41 am

Posts: 4
Joined: Mon Dec 17, 2012 1:31 am

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby Veqtor » Thu Aug 08, 2013 1:12 pm

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. :(

Posts: 19
Joined: Mon Dec 17, 2012 3:24 am

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby ESI » Mon Nov 11, 2013 8:49 pm

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.

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.

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?
Posts: 29
Joined: Mon Dec 17, 2012 3:22 am

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby Gravis » Wed Nov 13, 2013 4:29 am

Veqtor wrote:I want to access point cloud datasets using gps coordinates, and correlate that data with a kinect, or similar depth sensor, to try and acheive centimeter postion accuracy, even with low precision satellite information... :D

honestly, the hardest part of this project is making software that will turn the data into a model. it will take at least a year to get it working just right but it will totally be worth it because you can make super high resolution maps of anything and anywhere on the cheap. this is PhD level math and problem solving

as for the hardware, if you really want to do this right, you want a barometer, a laser distance meter, several 9 axis MPUs, an extremely high resolution stereoscopic camera and an average resolution stereoscopic camera, a camera gimbal and both large octocopters and smaller quadcopters. while you can do basic point cloud calculations in real time, you want to have a high resolution (lossless/no compression) video that you can use to post process and get much much higher accuracy clouds as well as textures. you would use the large octocopter (for higher stability) to do a systematic sweep of the area at a safe altitude. the quads would be effectively doing the same thing but they would be low and getting the details that were missed and have to be patched into the main pointcloud. you should also have a bright light to shine so you can avoid capturing shadows. that will get you the video you the high resolution video (and corresponding positioning information) that you want. after that, you have all the time in the world to process the images from the video to make the densest point cloud you can get. the gps should only be used for general positioning to be sure you stay in the area you are trying to capture. afterward, you match various landmarks from the satellite imagery and get exacting positions to correct any bad info and stretch the giant point cloud to the proper locations. moving objects in the video should be subtracted from the model or reshoot them when they aren't moving or you may end up with some bizarre looking trees. integrating all this information to extrapolate a textured model will take some serious math but the result will be map that trumps the ones that professional modelers make.

as far as games go...

what would make it really special is if you mark all the physical properties (density, viscosity, frictional force, material and generally how it's made/assembled) of the objects in the model so that you can have a 3d engine that can process what will happen if you hit a telephone pole with firetruck in your game that will actually show what part is going to bend/break where and how much and other interactions. however, it think that level of processing a models that dense and with so many physics interactions is a generation away. a matrix of 32K core epiphanies could manage it. that would make a great addition to a console.

frankly, the level of physics used in game engines is laughable. i mean, if my character jumps from a ledge, i dont want a preprogrammed distance at which the character just dies, i want my character to jump and break an ankle because of the slope or density of what they jumped onto. i dont want a health meter, i want them to bleed based on exactly where they are shot (internal organs and all) and passout/die when they lose too much blood. of course, like all game physics, you can tweak it so your character so that they can jump 30 feet in the air, has bones as hard as titanium alloy and blood pressure so high that blood that sprays out when they get cut, you know, classic anime physics. :)

manycore processing is the future of game engine physics.
User avatar
Posts: 445
Joined: Mon Dec 17, 2012 3:27 am
Location: East coast USA.

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby Veqtor » Fri May 16, 2014 11:11 am

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.
Posts: 19
Joined: Mon Dec 17, 2012 3:24 am

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby DanHouldsworth » Mon Jun 16, 2014 5:27 pm

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.

Posts: 8
Joined: Tue Aug 27, 2013 5:54 pm

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby cncbasher » Thu Jul 24, 2014 8:54 am

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 !
Posts: 1
Joined: Thu Jul 24, 2014 8:27 am

Re: Parallella Flight Controller / Robot / UAV Daughter Boar

Postby Grumpy Old Coot » Fri Aug 29, 2014 1:17 pm

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.
Grumpy Old Coot
Posts: 4
Joined: Thu Aug 28, 2014 9:01 am


Return to Daughter Cards & Accessories

Who is online

Users browsing this forum: No registered users and 3 guests