Difference between revisions of "Paul Cox Activity Log"

From PaparazziUAV
Jump to navigation Jump to search
 
Line 14: Line 14:
===Week 1===
===Week 1===
====3====
====3====
*Installed hokuyo driver on ubuntu netbook ("make" then "make install" from openrobots/sources/hardware/gbx-hokuyo-aist, required some [http://homepages.laas.fr/bvandepo/wiki/doku.php?id=hokuyo&s[]=gbx tweaks])
*Installed hokuyo driver on ubuntu netbook ("make" then "make install" from openrobots/sources/hardware/gbx-hokuyo-aist, required some [http://homepages.laas.fr/bvandepo/wiki/ tweaks])
*compiled and installed MTI drivers, opencv
*compiled and installed MTI drivers, opencv
*Compiled Bertrand's qt-creator project app (mac issues) and "test Windows" app (hokuyo & MTi to gdhe)
*Compiled Bertrand's qt-creator project app (mac issues) and "test Windows" app (hokuyo & MTi to gdhe)
====2====
====2====
[[Image:MTI_testing.png|thumb|MTi/MTi-G testing results]]
[[Image:MTI_testing.png|thumb|MTi/MTi-G testing results]]

Latest revision as of 08:13, 29 March 2011

Spring 2011

February

Week 3

Week 2

  • researched mt9v032/mt9v034 and omap3/omap4 camera interfaces
  • looked at built-in lvds interface of cameras and MIPI CSI1 and CSI2 of omap
  • Pierre will build an adapter board between his current dev board and gumstix connector
  • Gumstix will release camera product next week (caspapx) but does not have exposure or led pins routed to gpio
  • Continued hoku2gdhe app and put it on github (link on laserhawk page)

Week 1

3

  • Installed hokuyo driver on ubuntu netbook ("make" then "make install" from openrobots/sources/hardware/gbx-hokuyo-aist, required some tweaks)
  • compiled and installed MTI drivers, opencv
  • Compiled Bertrand's qt-creator project app (mac issues) and "test Windows" app (hokuyo & MTi to gdhe)

2

MTi/MTi-G testing results
  • Morning outside with Cyril and Bertrand gathering MTI and MTI-G data to check stability of data with new drivers
  • Afternoon continuing project documentation : drawing geometry figures

1

First Day

  • will use qt-creator for development
    • all code should compile for multiple target types
      • on host-pc (linux or mac) with graphical/visualizations for debugging with real or simulated sensors through logging
      • on gumstix (headless and with sensors)
  • Bertrand set up Xsens MTI/MTI-G testing with Cyril for tomorrow
    • We'll get on the roof and see if the MTI-G attitude estimates are as stable as those seen with MTI previously
  • Installed openrobots and started learning opengl and gdhe
sudo apt-get install libxpm-dev swig libxmu-dev libxt-dev apt-file libxt6 libxt-dev pax tar tcl-dev tk-dev libbz2-dev freeglut3-dev qtcreator
mkdir openrobots
cd openrobots/
git clone http://softs.laas.fr/git/robots/robotpkg.git sources
cd sources/bootstrap/
./bootstrap --prefix=/home/paul/openrobots

bertrand_opengl

  • Draft list of priorities/goals; see laserhawk page
    • Put XSens and Hokuyo on boom and record laser and attitude data
    • Camera images useful for initial laser/attitude debugging and potentially later for vision processing
    • Represent 3D data in graphical interface (opengl/gdhe)
  • Need to write up system architecture and general method formally
    • Show geometries / perspectives / etc
    • Link to all relevant documentation
    • more


Summer 2010

Develop beth detailed on Beth Test Bench page and overo/twog com detailed on overo page.

Sept 30

Put together notes for using PC joystick to control servos on twog (see Paul Cox Notes)

Aug 4

Some parameters I'm now using on beth:

link -udp -transport pprz2
server -no_md5_check option
settings -ac BETH

other useful stuff:

ivyprobe '(.*)'
export PPRZ_DEBUG='*'
export PAPARAZZI_HOME=/home/paul/paparazzi3/trunk
export PAPARAZZI_SRC=/home/paul/paparazzi3/trunk


June 2010

June 23

Compile beth projects :

main overo - reads/writes SPI main_stm32 - runs on lisa STM. fetches values on I2C from olimex board, sends to overo main_coders - runs on Olimex header board. samples ADCs sends messages out of UART for debug and I2C slave

Seeing issue where lisa stm32 crashes randomly. seems to occur less often if periodic loop less frequent (for example reduce from 512 to 256 or 64)

attempt to debug with logic analyzer from saleae.com

June 22

Finish Beth schem/pcb take to ENAC with steel axle

available from:

http://code.google.com/p/enac-lara/source/browse/#svn/trunk/paul/beth

June 21

rt2780usb

Tried to get rt2780usb wifi dongle working with lisa, no luck : the adapter is recognized at some level as I get the following messages :

output from gumstix

usb 1-1.4: new high speed USB device using musb_hdrc and address 6

usb 1-1.4: New USB device found, idVendor=7392, idProduct=7711
usb 1-1.4
: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.4: Product: 802.11 n WLAN
usb 1-1.4: Manufacturer: Ralink
usb 1-1.4: SerialNumber: 1.0

lsmod output:

Module                  Size  Used by
ipv6                  219420  1
0 
rt73usb                20604  0 
rt2x00usb               9154  1 rt73usb
sg                     21442  0 
rt2x00lib              26540  2 rt73usb,rt2x00usb
ads7846                 8395  0 

output from karmic pc:

[221517.285099] usb 1-4: new high speed USB device using ehci_hcd and address 62
[221517.440249] usb 1-4: configuration #1 chosen from 1 choice
[221517.476238] phy8: Selected rate control algorithm 'minstrel'
[221517.481524] Registered led device: rt2800usb-phy8::radio
[221517.481663] Registered led device: rt2800usb-phy8::assoc
[221517.481793] Registered led device: rt2800usb-phy8::quality
[221518.171887] udev: renamed network interface wlan0 to wlan13
[221518.213665] rt2800usb 1-4:1.0: firmware: requesting rt2870.bin
[221518.746845] ADDRCONF(NETDEV_UP): wlan13: link is not ready

Since the adapter works perfectly on my karmic pc and I noticed that there a firmware bin file was being requested, i copied it over to the gumstix in /lib/firmware but still no luck. I tried the latest prebuilt binary image (June 18) from gumstix and still the same behavior. Perhaps I need to configure something...

USB OTG as host testing

Interfaced a hub to the USB OTG port. bridge the ID pin to GND and run USB+/- and VBUS to the hub. Supposedly hot-swapping is not supported (must boot with device plugged in already) but that could be an old issue and that works now.

June 17

Setting up paparazzi source and OpenEmbedded to compile for LISA:


 sudo apt-get install paparazzi-stm32
 sudo apt-get install gtkterm

 ls .ssh/id_rsa.pub
 cat .ssh/id_rsa.pub

 vi /home/paul/.subversion/servers
 =====================================
 Uncommented :
 [groups]
 group1 = *

 ### Information for the first group:
 [group1]
 http-proxy-host = squid
 http-proxy-port = 3128
 =====================================

svn co svn+ssh://paulcox@svn.savannah.nongnu.org/paparazzi/paparazzi3

cd trunk
make
cd paparazzi3/conf/
ls
gedit conf.xml
vi conf/airframes/Poine/booz2_a7.xml
vi conf/autopilot/lisa_test_progs.makefile 
vi conf/Makefile.omap
sudo cp conf/system/udev/rules/10-paparazzi.rules /etc/udev/rules.d/
sudo /etc/init.d/udev restart
sudo vi /opt/paparazzi/stm32/share/openocd/scripts/interface/openocd-lisa-jtag.cfg
make AIRCRAFT=BOOZ2_A7 test_led.upload


vi conf/airframes/Poine/beth.xml

make AIRCRAFT=BOOZ2_A7 overo_test_periodic.upload


make AIRCRAFT=BETH overo_test_link_stm.upload
ssh-copy-id paul@auto7
ssh auto7
./overo_test_link_stm.elf 


Used gtkterm to connect to ttyUSB0/1? to connect to Overo console. login as root with no password. ran dhclient wlan0.

Jan 2010

Had to pack up all my stuff this summer and just now starting to get back into UAVing. First on the list is to get a plane in the air. I brought most my electronics with me, and the lab is letting me use a foam plane so I should be flying soon. I'm also hoping to start on quadrotors so I can get more familiar with them and help document it. Other things on the task list: Design a tiny with an overo SPI connection.

Nov 2008 - Jan 2009

Installing Software on Ubuntu Intrepid Ibex 8.10

Used CVS to download "paparazzi3". also discovered Booz guys are using svn and that repository is called "paparazzi4".

Read the wiki multiple times through, built everything acording to instructions, and fired off the program which seems to run in simulator mode, although I'm currently not seeing any action when I hit the "Launch" button. I probably haven't read something important somewhere...

Gather hardware:

Looked at the hardware designs in CVS to see if I wanted to customize a design or build one of the "released" designs. In summary, the current things folks are building and using are:

Autopilots

  • Tiny 1.3 - ARM processor and GPS on 4 layer PCB with 0402. Benefits: smaller and 4 layers is more reliable Drawbacks: Design is older and has evolved so there are some missing feature and maybe some issues (Insert more specifics here as I learn them)
  • Tiny 2.11 - ARM processor and GPS on 2 layer PCB with 0603 SMT devices.
  • TWOG - Tiny 2.11 without GPS. I assume people want to branch out and use different GPS and not just the u-blox stuff. Also I see mention that some people want to mount GPS hardware some place different on their airframe than where the autopilot resides.
  • Booz - Some very exciting quadrotor developments. HW Design not checked yet as there's some errata that someone feels like needs to be fixed before it is commited.

Sensors

  • Single Axis IR - For two Melexis thermopiles
  • Dual Axis IR - For four Melexis thermopiles
  • GPS board - A PCB to hold just a GPS and an antenna. For use with TWOG


Looked at how much to have the PCBs fab'ed by quick turn board house, but unless you order 25 or more PCBs you're better off buying from the listed vendors. I went with PPZUAV:

  • single IR PCB $8
  • Dual IR PCB $8
  • Tiny 1.3 PCB $9.95
  • Tiny 2.11 PCB $5

$6.80 shipping (California to Washington)

I check first to make sure all was in stock, and David replied that it was. Order took a couple days to process and a few days for the post office to deliver the priority lettter. PCBs arrived in a little padded envelope and even though I knew the dimensions before, I was surprised at how small they are in the flesh.

Components were mostly from Digikey: TI DC/DC was only available in SMT and no shotkeys.

Complete List: (insert spreadsheet here)

Mouser had the switching DC/DC in through-hole and shotky diode so put in an order with them as well:

Of note: Looked for GPS modules and antenna and found some items of interest. A Tyco GPS module with a built in antenna for $60 []. Also antenna [].

Different center frequencies are available 1575 MHz and 1579 MHz, but googling seems to show that 1575 is the main GPS freq. Not sure what 1579 is useful for, but it kinda looks like the one paparazzi recommends from their testing is centered at 1579 so I must be missing something.

Complete List: (insert spreadsheet here)

While waiting for all the hw to arrive, built a wireless GPS device:

Main components:

  • Wireless modem: XBee Pro 802.15.4 (XBP-24-AUI)
  • GPS:
  • Battery: 2S Lipo (gutted Axim x50v battery, rewired from parallel to series)
  • Antenna: Some rpsma? wifi antenna I had laying around with a u.fl connector/pigtail.

Other components

  • TI DC/DC converter (same as used on tiny)
  • 100uF tantalum capacitor (TI DC/DC conv requires this on the input)
  • SPDT toggle switch
  • Samtec mating connector for GPS
  • kynar wire
  • plastic box and some thin model plywood for a case

Receiver is another XBee Pro in a USB carrier board. The XBee Pro has a wire antenna (XBP-24-?UI). Looking back I should have ordered with the RP-SMA so I can put some coax on there to a big honkin' antenna to improve range.

Build process:

Main obstacle here is the fine pitch connector on the GPS module.

XBee Pro and the GPS module are 3.3V devices. For the TI DC/DC used on Tiny to produce 3.3V a 1.87kOhm resistor is needed an input capacitor of 100uF is needed. I wired up all these components

Bring up process:

Getting things talking was suprisingly easy. XBee devices come pre-programmed and configured for transparent mode at 9600bps. There's destination and source addresses and all sorts of configurable stuff, but out of the box two XBee will just find and talk to each other (great job guys!). Transparent mode basically means that both the devices send traffic to each other transparently, so essentially the end devices don't need to know anything since the XBees just look like a wire.

The GPS module provides NMEA data at 4800 baud so I needed to reconfigure the XBees for that lower baud rate (I may not have needed to do both, but I did anyways). Doing that involves getting out of transparent mode and into command mode (done by sending characters "+++") at which point a few "AT" commands are used to change the rate and save the setting to non-volatile memory.

By the way, Digi also makes a windows application available called "X-CTU" which is very useful. It will test communication with your XBee device, read/write the module's settings, and has two other very useful modes: A range test mode where the the Xbee on the far side of the link has had it's

RX/TX pins wired together for loopback and signal strength is displayed; and a terminal emulator that works nicely (I had a heck of a time finding a good terminal program that worked with my COM26 device, looked good, and was easy to use. No matter how much .ini hacking I did I couldn't get teraterm to look beyond 4 ports).

So first to validate that my DC/DC is providing power and the GPS works, I hooked up a GPS to a serial/USB converter (from acroname) to the GPS RX/TX pins and plugged the USB cable into my laptop. Turn on power and sure enough, lots of NMEA looking stuff spews forth. Next rewired the GPS to the XBee and plugged the USB/XBee device into the laptop and, voila, same data shows up as before but this time the GPS device is totally wireless.

Now I wanted to get more than just a bunch of NMEA strings on a terminal window, I wanted to see the position in google earth or google maps. I bought the plus version of google earth and had used it with my Garmin Etrex Vista successfully, but it turns out that it doesn't work directly with an NMEA COM port based device (at least for me). Instead, there are a number of folks out there that provide little command line programs that open the com port and crank the data out in xml via http socket. Google earth can open a network location.

Tiny v2.11 Assembly Process

Once all parts arrive: sorting components and getting BOM and component placement references ready for use. Wiki has all this info nicely laid out.

  • PCB silkscreen and wiki image (Tiny_v2-1_2D_top.jpg) have LED1 and LED2 reversed. Not sure which is correct yet.

Since there's more components on the CPU side, that's the side I populate first. Starting with smallest components to largest makes assembly the fastest.

Once all components mounted and the input power wires are soldered, time to apply power. I used a benchtop power supply so I could monitor current.

With a voltage input of 7.0V, current should be around 50? mA.

Now attach IR sensor boards and USB connector along with wires for other interfaces (serial, download, rc receiver -- I'm waiting before doing servo wires to keep things tidy until later)

First order of business is to download USB bootloader over the serial port. This uses the "Download" serial port so you have to disable the GPS, but I hadn't populated it yet so didn't have to bother with disabling it.

Now that there's a USB bootloader, downloading code into Tiny just requires plugging in the USB cable, powering up, and sending the code (which is either done with a "make" command or pressing the "Upload" button in Paparazzi Center.

Now to run a simple program: LED test. Some nice instructions on getting this going are [here].

All goes well and three LEDs are blinking.

Now download autopilot code. A direct connection of the serial port to a USB-serial adapter plugged into my PC relays the telemetry data. Firing Paparazzi Center and executing the session "Flight USB-serial@9600" shows battery voltage so I'm up and running.

Now I attach the IR boards

Mounting

Messy Hardware

Mounted Tiny
Mounted Tiny

Things are getting sloppy and afraid something will short and fry, so it's time to mount things to get things under control. I had some plastic cases that some lenses came in which happen to be just the right size. Tiny, my 2S lipo, and an XBee fit in one side perfectly, and the other side can be used for extra wires, the USB connector, power switch, and the RC Receiver. The IR sensors are hot-glued on the exterior using a little balsa. Probably won't be useful when it comes time to fly, but it's compact and sturdy which is what I need until I'm ready to start thinking about flying...


Configuration

I started with the funjet1.xml airframe file because I read others use that with the Tiny2.11. I don't plan to use a dual elevon plane (instead will do a standard rudder/elevator/ailerons setup) so will have to make lots of changes -- not a bad way to learn how things work... The Airframe Configuration page is a great help here.

  • Battery voltage - The default looks to be setup for a 3S battery and perhaps my resistor devider resistors aren't the right values, so GCS reports incorrect battery voltage. Instead of hunting through the code I vary the voltage on my power supply, watch the output, and empiracally find the correct values to set:
<section name="BAT">
 <define name="MILLIAMP_PER_PERCENT" value="0.86"/>
 <define name="VOLTAGE_ADC_A" value="0.0245"/>
 <define name="VOLTAGE_ADC_B" value="0.1"/>
 <define name="VoltageOfAdc(adc)" value ="(VOLTAGE_ADC_A * adc + VOLTAGE_ADC_B)"/>
 <define name="CATASTROPHIC_BAT_LEVEL" value="6.4" unit="V"/>
 <define name="CRITIC_BAT_LEVEL" value="6.8" unit="V"/>
 <define name="LOW_BAT_LEVEL" value="7.0" unit="V"/>
 <define name="MAX_BAT_LEVEL" value="8.4" unit="V"/>
</section>
  • IR:
    • Mode - I change from to tilted to aligned mode because tilted mode seems weird.

remove:

 <define name="HORIZ_SENSOR_TILTED" value="1"/>

add:

 <define name="HORIZ_SENSOR_ALIGNED" value="1"/>
    • Neutrals - The "cupboard test" shows the neutral values are pretty close already.
    • Direction - Tilting the sytem around, I see that one of the axes is reversed so I set IR2_SIGN and TOP_SIGN values accordingly:

insert here

    • GPS - For LEA-5H u-blox module: add -DGPS_USE_LATLONG in makefile portion of airframe xml file as per instructions on wiki []. I still get some error messages, but they stop after a few seconds and all seems to work.