How to setup an Overo to work with your AP -- This is just a quick run down even though a long post
This will show BASIC functionality of how to get the UAV DevBoard and the ArduPilot working. The rest is up to your imagination and the recipes you come up with and the add ons you want as well. I am sure there may be cleaner and better ways to interface the two but this was the easiest for me to be able to get the functions on board the plane i needed.
I will be showing you the ways I was able to use my gumstix overo fire and summit expansion board with my AP's. Tested with both the UDB V2 and ardupilot with v2 shield and xyz sensors
First and foremost you will want to make sure you have properly built and setup your build environment for the gumstix overo. You will also want to make sure you have setup your user.collection section properly and copy over the entire linux folder from the OpenEmbedded recipe selections. This way once you setup the kernel config your defconfig file will always stay the way you set it up. I will only discuss changes I made that pertain to getting the AP and the overo setup. A tip on everything from here on out is to make sure your build environment is setup and WORKING properly. This was not simple for me and took a long time to fine tune, and the build chain breaks all the time. Also my other tip is once you have a version of the branch your on you like make sure you make a branch from that config in case your next git pull breaks something. Which trust me happens way more than you want.
Once you have that all done and setup you will first want to just build a basic image:
bitbake omap3-console-image
By doing this you build everything you will need and the kernel will get built. Grab a drink or go do something else it will take a long time even with a fast internet connection the first time.There are many kernels to chose from depending on what you want to do with your setup and to set the preferred kernel version in your overo.conf file you will want to add this line to the file:
PREFERRED_PROVIDER_linux_omap3 = "2.6.32"
Now if you want to choose a different kernel make sure you change accordingly. Once you have built the kernel you will want to go in and customize it. The way you want to do that is through bitbake:
bitbake -c menuconfig linux_omap3_2.6.32 * I am currently running the psp kernel
Technically you do not need to reconfigure the kernel but I went in and added all i2c debugging and options that there were so as to make sure my kernel had anything it would need while working on this. I would recommend you do the same as well just so you can make sure as you go and add things on you have any functionality you need. Or say if you know future needs you want to add in you might as well set them up now so you have less chance of reconfiguring the kernel again later, other things to keep in mind are if you want to use a USB camera you will need to make sure you configure the kernel to use that as well (this is a not difficult process and if needed can post the way to get the camera and drivers and modules if your camera can work in linux should be fine). I also made sure to setup iptables properly. Also you might want to do any security configurations at this time as well. I will not go into any of that as its way out of the scope for here. Honestly there is a ton of different things for the kernel to keep in mind and this only BRIEFLY touches what you should do. And as this is going to be long as it is, I am trying to keep this slim in case there is not really much interest.
Now you will want to take your image you made and install it either on the nand or sd card. The first time you boot your image it can take anywhere from 10 to at the longest its taken for me was 75 min for the first boot, this is first boot only. For the sd card use at least a 8gb and if you want more room for HD space you can use a thumb drive your size of choice. 60 GB for me :)
Now if you want to change an the clock you will need to get into uboot you will want to reboot your system now and once it reboots hit enter in the 5 seconds you have. Now enter the following commands:
printenv ( This will show you your current environment variables you can take note for safety sake)
setnenv (Your new boot args or so on)
saveenv
restart
setnenv (Your new boot args or so on)
saveenv
restart
For both applications you will need a SparkFun logic level converter. Was the cheapest and most recommended to me for this. You need this because the header on the overo is 1.8v
I also chose to run an XBee and this setup to transmit my telemetry info back, basically a failsafe telemetry. So to do this I made basically a y harness. So that way you can connect the overo and XBee together.
Now for connecting it:
From the summit board 40 pin header take pins 9 rx and pin 10 tx and put those on to the logic level converter on their corresponding pins on the LV side. Now you will want to run pin 26 your 1.8v and 25 ground to the LV side of the converter. Now from the HV side of the converter board you will want to run a power and ground to it, I just ran a Y cable from what would go to the XBee and hook up your power and ground to the HV side and connect the TX of your AP to the RX pin on the HV side of the converter. Bingo thats it.
There are a bunch of great pins you can access on there, I am using the serial port for the AP as well as using the i2c interface.
Now from your overo a simple connection to read the stream is as follows:
#!/usr/bin/python
import serial
import sys
import struct
if len(sys.argv) !=3:
print "Usage: UAVser.py <seria lport> <baud>
ser = serial.Serial (sys.argv[1], sys.argv[2], timeout=None)
try:
while True:
sys.stdout.write(ser.read())
sys.stdout.flush()
finally:
ser.Close()
print "Closed"
This is nothing more than a test program to make sure you can get the serial stream on your overo.
If there is enough interest I can post more information, programs and maybe other tutorials with what I have done with adding a full blown computer on board with our AP's. Though basically everything I have written are either bash scripts or C, python and perl programs and none are anything to fancy, most of what I do on board is just using existing linux programs. I log everything to a single file and that goes into a database on the overo. Then my on board programs read the data from there and fills it in appropriately to the programs, while also keeping an entire running log. I have one program that collects the info from the AP and sends it back on a dedicated wifi link to be displayed on the GS laptop. I am running a basic USB webcam running a program I wrote that uses ffmpeg for now to stream the video and I also have it place some of the telemetry stream on top as a dirty OSD type setup. The video and OSD are nothing fancy and were just because I had a camera laying around and got frustrated with some other stuff one night and got it to work "good enough" for now. I also have a 4-port powered USB hub and 2 ALFA USB wifi adapters on top of the on board wifi on the overo, as well as the on board bluetooth and a USB bluetooth adapter. Currently the CPU usage on my overo with the video and if I have everything running which is 35 separate scripts or programs wifi related and 10 bluetooth related, and the on board wifi and bluetooth both running, sqlite making its DB I have only hit a max of 67% cpu usage with the chipset running 720mhz. There are more functionalities I have added as well but most would be of no interest to people here.
You can also hook up both AP's by means of i2c but its more complex to configure and you need to add code to the AP your using if you want to get the fully functionality out of the connection and the time and hassle to do so. I have run both AP's connected in both manners (serial port & i2c). Though I am have more time with the UAV Dev Board V2 than my Ardu setup in both configurations. Also if they are wanted I can post pictures of the connections
Thanks to:
Everyone here on the site who listened to my ramblings and helped me with my problems, Chris and Morli especially! A big thanks to Bill P. for making the DevBoard and Jordi for the Ardu :) a huge special thanks goes out to my son!
Sorry for the bad pics, I dont have a good camera at this time to take pictures. I will also post more configuration pictures in a reply in a few days when the camera shows up.
-
Moderator Comment by Morli on August 28, 2010 at 6:46am -
Good work Jermy, looking forward to learn more about integrating or using Overo fire. Thanks for sharing.
-
3D Robotics Comment by Chris Anderson on August 28, 2010 at 7:24am -
Jermey, could you include a picture of the setup? I don't think most people know what an Overo is.
-
Developer Comment by Pete Hollands on August 28, 2010 at 9:24am -
Jeremy, thanks for the post. Currently many of the core developers of the UAV DevBoard (MatrixPilot) use the openlog for storing the telemetry. Connecting a full blown linux computer for higher level telemetry, and higher level navigation was going to be the next step / possibility. Thanks for doing that, and sharing some of your tips. Best wishes, Pete
-
Comment by William Premerlani on August 28, 2010 at 12:13pm -
Hi Jeremy,
You are quite welcome, I am sure. Thank you for posting.
Best regards,
Bill
-
Comment by Jeremy on August 28, 2010 at 1:38pm -
Thanks guys I will post some pictures for you very shortly, sorry about that one. :) Glad you liked so far.
@Pete if you wanted to go that route the i2c would be your best way, I am currently doing something like with the v2 board. Though I was going to get v3 last night but they are out of stock for a few weeks Bill said in an email. If you would like some help or more info I would be happy to what you guys want to do may, have a huge start already by me. I honestly prefer the i2c method as it gives you more options and really put the power of both to their full limits.
-
Comment by hamadivo on August 28, 2010 at 4:02pm -
Nice post!
i'm using gumstix verdex pro ... soft and hard implementation in progress .
specs:
SPI : airspeed, IMU 6DOF (EKF), magnetometer
I2C : servo commander, pressure
RS232 : GPS, RF link
USB : webcam
SD card logger
-
Comment by Jeremy on August 28, 2010 at 4:18pm
-
@hamadivo right on sounds like a nice setup. :)
Whats the webcam you are using? I had to write a driver for the cam I had since it was some random cam I found laying around. Most people have said the logitech to be the best for linux and I want to add another camera to my plane so I can get two visual perspectives streaming back to my GS. And the one I have is not the best since I am no linux driver master.
For my i2c connection though I have a recipe that will implement the DevBoard in the build of the image, I have not been as lucky yet with the ardupilot but its just a matter of debugging more and I have had less playtime with my ardupilot. I have been messing around a bunch getting the UDB as integrated with the overo as much as possible but really only in the matter as it would help what my end project was/is.
-
Comment by hamadivo on August 28, 2010 at 6:19pm
-
I used uvc driver, here is the link for using it with gumstix :
http://www.gumstix.net/wiki/index.php?title=Webcam_drivers_-_Mini_H...
http://www.ideasonboard.org/uvc/
About I2C, i tested it with HP03D Pressure sensor (3.3v logical level).
-- add the folowing lines to /etc/modules
# I2C
i2c-dev
i2c-pxa
-- add the i2c include files
#include "i2c-dev.h"
#include "i2c-api.h"
#include "i2c-io-api.h"
and use : I2cSendBytes to send bytes and I2cReceiveBytes to receive.
-
Comment by Jeremy on August 28, 2010 at 6:48pm
-
Yeah the cam I use isnt a supported uvc cam It was a windows only cam from 1999 I think :) Thats why I had to write a driver, not to hard just time consuming. But I think I will go with some cheapie logitec cams as they seem the most actively used. Thats basically how I have the setup done with i2c, I just have a recipe that loads all the UDB programs I wrote and loads the proper modules and everything in the image build, I did not want to go into the i2c connection on this post as its way more complicated and you have to modify the AP code to get this to work properly, at least I did but how I managed to do it works great for my needs and seems to be efficient enough for now. I went about it in a little bit different manner as I am not looking for the overo to have any real control over the AP in the air just use all the info from the AP and I do my cam tracking on the overo. Then any additional sensors I have added can be attached to the overo to run and if I wanted could in turn send it back to the AP.
My project really did not need to really do much with the AP things thats why I went with already proven AP platforms, I needed the real computer in the air to take care of what I need in the air and make some things easier. I figured why re invent the wheel on the AP, but there is a ton of possibility to offload processing of certain things from the AP to the overo as I can still crank more processing power out of my setup.
I have cleaned up a bunch of programs and made them way more efficient and a 15 min test flight today, I was able to bring down my full running processor usage down to 43% and I was streaming video while sort of tracking a specific point I was loitering over and tracked sorta a moving bluetooth signal with the camera. As well as a bunch of other non AP related things. So a total of 52 scripts and programs ran and deployed on the mission as well as the video work and databasing the telemetry file as well as creating DB's for the programs and scripts to use the telemetry as needed.
-
Moderator Comment by Morli on August 28, 2010 at 8:15pm -
Very interesting work Jeremy. You can start part 2 for I2C related details and multiple parts thereafter for related subjects of your project. I am sure it will well received and appreciated. Bunch of us would like to integrate additional sensors or want to have possibility of adding them as required. Though APM and UDB4 will take care of it onboard but adding Overo to older version can bring more juice to its life span. I personally wanted to have sensors like engine temp( gas /nitro using cheap SF temp sensor) , payload / outside temp, pressure sensor, ultrasonic altimeter, adding small repeater controller( for telemetry or RC control relay ;) ) etc. Initially these need not do any thing with AP , just passed on to telemetry stream for display at GCS. Current telemetry can be offloaded to Overo for processing ( or reducing load on UDB) or compression if possible and adding 2 way telemetry( WP uploading) etc. This may be too much to ask but no harm in requesting I guess. Thanks for sharing.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1288 members
-
Moderators
24 members
-
Australia
78 members
-
Documentation Editors
51 members
-
ArduPlane User Group
682 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
You need to be a member of DIY Drones to add comments!
Join DIY Drones