Diary June2005

From Albatross

Jump to: navigation, search
This article is part of the diary. For all diary entries please select by month below.
2006 • August • July • June • May • April • March

30th June

  • Fixed stupid threading issues in the Python Ground Station. It turns out that nanosleep() used in datagram.c->pause_recieve() is somehow blocking the Python thread scheduler (i.e. using 99 % of the CPU time available to the scheduler - so other threads ran, just really slowly). So Pthreads in C modules are fine, and the original datagram Pyrex bindings are back in used, with the call to nanosleep replaced with time.sleep (the precision is the same on Linux due to the rather high granularity of the system timer). The Python threading model and implementation is in desperate need of an overhaul...

29th June

  • Ordered the new GPS antenna from here.
  • Laid out a quick and dirty MMC board.
  • Tidied up HWD a bit.

28th June

  • Tested GPS outside. It (just) works but only if Snapper is not powered, and even then it takes about 5 minutes to get a fix. With Snapper on there... nothing. Drove around the block a few times (one of the times it was working) and it worked fine (direction, altitude and speed and so on all work).
  • Decided to get a new GPS antenna and that means a new connector is needed on the PCB as well.
    • GPS MCX Female (Jack) Farnell Number 8104581 I think will work nicely, along with a new GPS antenna like this.
  • Hitting some pretty bad issues with the Python<->C bindings for the IPC stuff. Update: Fixed, stupid problem, see 30th June above.

27th June

  • Can't get the radios working... tried absolutely everything we could think of to get them going. They responded almost as if they were RS-485, and would only output anything at all if we touched to scope probes against the pins, giving some kind of differential voltage... to test that theory, we cut the metal shield off one of the modules and it in-fact did not have an RS485 chip (but instead had an empty RS484-looking footprint. But they were not completely dead - the "In Range" light came on when both were powered up and had antennas attached.
  • Ordered new radios from Mouser - in fact we ordered a development kit so it can't possible go wrong. Don't buy from RF Design, we wasted about US$200 on those radios :)
  • Worked on ground station, hardware interface daemon and state daemon (numerical integration and converting reference frames) today.

26th June

  • Got the servo drivers on the FPGA working.
  • The SPI sequencer/controller now works, so most of the development on the FPGA has been completed. The Altera tools (Quartus II v5) proved instable, hard to use and just stupid, it gives many many pages of output as it compiles things, the usefull messages are swarmed by useless ones, and its near impossible to see whay actual logic has been inferred from the VHDL. I Prefer Xilinx a great deal at this point.
  • Having some trouble getting the radio going... If we fail, at least mouser stocks them, so if we have broken one we can buy another.
  • Patched in the I2C code into the kernel.

25th June

24th June

  • Last two days have been a lot of FPGA work. We can now read from all 8 channels of the inertial sensors ADC (3 gyros, 4 accelerometers and temperature), but there are still some small problems. The ADC is sampled automatically without CPU involvement, and all 8 channels are locally buffered, so reads are asynchronous with respect to sampling and have very little overhead. A read is always the latest available data, but the CPU does not have to worry about selecting the desired channel, starting the conversion and so on - that is all done by a state machine in the FPGA.

23rd June

22nd June

  • Added Python bindings to udp_multicast.h and datagram.h using Pyrex (amazingly cool tool!). See the PyDocs here.
  • Modified the header generator to also emit Pyrex code from the Protocol definition spreadsheet that is used by the Python binding to datagram.c
  • FIXME ASAP: John, Can you please make some changes to your datagram code:
    • I have fixed udp_multicast.c for better error handling (returns less than 0 for error) but don't know where it will affect your datagram code. Can you check/fix it please.
    • Finish the transition from datagram_t to datagrizzle_t (and perhaps fix the name back to datagram_t if you want).
    • Fixup/finish error handling in datagram.c.

21st June

  • Minor code tidying up, fixed up all the Makefiles (top-level make and make clean work, all support cross-compiling where needed).
  • Thought some more about Kalman filter, e.g.:
    • How to choose the state vector?
    • What order/topology to perform the computations in (i.e. Kalman filter on coordinates transformed to the world frame or Kalman filter in local body frame coordinates)?
    • Or do we have two Kalman filters, one combining acceleration and gyro measurements to get attitude, another combining acceleration and GPS measurements to get position and velocity?.
  • Printed out a bunch of papers and thesis' about Kalman and INS/GPS stuff.
  • FPGA work - wrote and SPI master and sequencer for the AD7888 ADC (used for the inertial sensors readings).
    • Kindof sortof works... or at least parts of it work... but it fails to meet the timing requirements (100 MHz FPGA system clock), so some optimization is needed.

20th June

18th June

  • Thinking about Python bindings for the C libraries we wrote/use for interprocess communication, in relation to the Groundstation architecture. I think we will use SIP to auto-generate the bindings (in the form of a Python module that has near-native performance[1]) from the C header files (augmented with some extra SIP configuration code).
  • Added preliminary graphing/plotting support to the Groundstation application, using Matplotlib. Although it was slightly annoying to install (not in apt-get), and quite resource-hungry, it is very easy to use, rich in features, and produces a quality anti-aliases output. For instance, support for zooming and navigating plots is free (by using the NavigationToolbar class), as is support for exporting plots to common image formats. Supports all major OS's and windowing systems.

17th June

  • Got the FPGA running some code to check the CPU<->FPGA memory interface was working. A six hour battle with Quartus taught us that the following settings needed to be enabled or else programming would freeze, and the CPU would brown out.
Quartus Settings: (stupid Quartus, why on earth would unused pins drive ground by default!!?!?!)
  1. Assignments->Device->Device & Pin options->Unused Pins Tab->Reserve all unused pins as inputs, tristated. (Was causing the CPU to brown out...)
  2. Assignments->Device->Device & Pin Options->General-> Enable INIT_DONE output. (Was causing programming to freeze)
  3. Assignments->Device->Device & Pin Options->Programming Files->Raw Binary File .rbf
  • Toggled some IO pins on the FPGA from a C program on Snapper.
  • Wrote a minimal software SPI controller in C to check the SPI ADCs and pressure sensors work. This ran at a maximum of 100kHz which is ridiculously dissapointingly slow, and shows that we might have to write a SPI master in VHDL (the soft SPI is wasting about 1600 CPU cycles per byte transferred - 5 accesses to the FPGA per bit, 8 bits, about 40 cycles per access to the FPGA... the CPU <-> FPGA interface needs to be tuned). Although the VHDL SPI master was our initial plan, it would save alot of work by replacing it with a software SPI controller.
  • Power consumption (ethernet off, running hw_test.c in a loop - soft SPI master clocking out data, 100% CPU load) is down to 210 mA @ 7.2V (1.5 W total). The current can increase to about 230-240 mA when running benchmark software at the same time (in the background). 170 mA idle, ethernet off.

16th June

  • I built/ran STREAM, a simple benchmark of memory bandwidth and FP speed. It runs 4 tests; the first test (Copy) only tests memory bandwidth, the others (Scale == FP multiply, Sum == FP add, Triad == FP MAC) test FP speed. It uses 45.8 MB of memory so it is also a good test that the kernel (malloc) and memory is working properly. See Benchmarks.
  • Trying to build a new Soft-Float-enabled GCC toolchain... DONE! after many problems. Great floating point performance (see Benchmarks), same integer/general performance (no detrimental effect).
  • Rebuilt/ran Dhrystone v2.1 benchmarks again, results as expected. It seems earlier Dhrystone benchmarks I did were flawed, but I think these ones are valid.
  • Backed up everything to date :)
  • Converted everything over to the new soft-float toolchain (toolchain libraries, kernel, user-space utils), very painful. Everything seems to still work though.
  • Started pulling together some FPGA code for a hardware test mode (where all the FPGA IO pins are exposed to software as programmable GPIO pins). See fpga/ in the SVN.
  • Updated Benchmarks and Xscale Toolchain.

15th June

  • More floating-point benchmarking on the hardware... I decided to write my own FP benchmark because the Linpack-derived one was confusing and I think it wasn't giving correct mega-FLOPS readings. My benchmark is ridiculously simple (and probably incorrect), and just times 1,000,000 iterations of each of the operations (add, sub, mul, div). Results: see Benchmarks.
  • TODO: investigate software (C-compile time) soft-float.
  • Worryingly, the AVR processor and C-library seems to be able to get much better performance per clock for DP (versus the NWFPE, because the FastFPE has no double mode). According to this, the AVR takes around 550 cycles to do a DP multiply. Based on the above numbers (NWFPE, double) on the 400 MHz XScale, a DP multiply takes around 616 cycles (and I assume it is running in cache for such a short/simple benchmark, so things can only get worse). But it is worth remembering that with an emulated FPU, every FP instruction involves at least two context switches. According to this, with the NICO soft-float patches in GCC we should be able to average about 5x faster than FastFPE.

14th June

  • Investigating how to efficiently store and do operations on matrixes (e.g. multiply). There are heaps of C/C++ libraries around such as Blitz++, CheapMatrix, and Meschach. The best one seems to be Meschach (plain C - not C++, fastest according to [2], free).
  • Conclusion: I think we only need very simple operations (add, multiply), and I don't think we need more complex stuff (eigenvalues, inverting), but Meschach is light-weight and fast, so we may as well use that anyway.
  • Trying to decide which Kalman filter (KF) to use: plain-old linear Kalman filter with linearized equations of motion (EoM), or some more complex non-linear model/EoM and associated Extended KF (EKF) or Unscented KF (UKF). Also trying to decide whether we want to have a full inertial navigation system (i.e. attitude/anglular-rate and position/velocity/accel. out of the estimator) or just attitude i.e. AHRS (attitude and heading reference system) (i.e. no position/velocity/accel. from inertial data - we can get these from GPS after all). It seems AHRS-only is actually very simple...

8th June

  • The final Farnell order came and these parts were placed on the board.
  • This marks assembly as complete (and photos will be added to the Gallery ASAP bump - John pls).

7th June

  • Placed the final parts order from Farnell (Hopefully).
  • Researched into I2C comms on the PXA and the AVR.
  • AVRlib looks promising as a basis for the I2C code. It is quite complex in places, I also found a simpler implementation at here, which is part of the BTnodes development system.
  • AVRlib also has a simple GPS/nmea library which may form a basis for the snapper code.
===6th June===
Assembly progress at the end of day three.
Enlarge
Assembly progress at the end of day three.
  • The op-amps for filtering the IMU signals were placed and seem to work as expected.
  • Placed the level translators. When these were powered up there seemed to be too much additional current drawn. This was traced back to the pressure sensor ADCs having the incorrect footrpint. This was fixed.
  • Noticed that this didnt fix the additional current draw. We decided that this was due to the pressure ADC taking power from the level translator when its supply is not connected. Added pull-down resistors to the level translators to solve this time until the FPGA has been programmed (See PCB Errata).
  • Tested the pressure sensors, we seem to be getting valid data from them.
  • Placed the DS1722 temperature sensor.
  • Placed all of the remaining passives on the board for cleanliness.
  • We will not place the CAN circuitry or the thermocouples (at this stage) as they are not required.
  • Placed the expansion connectors on the back of the board and assembled two mating breakout boards.
===5th June===
Assembly progress at the end of day two.
Enlarge
Assembly progress at the end of day two.
  • Can program AVR, can control power supply enable pins, can reset snapper from the supervisor.
  • The analog switch works, successfully switching signals between the supervisor and snapper. We did connect this to the wrong supply however (see PCB Errata).
  • Some PSU enable pins were not working, had some left over solder paste shorting to a via, underneath a capacitor...
  • Put on Snapper. It works, yay! So Good! Spent ages working out serial console. Turns out the schematic was wrong for the simplest of things... in the MAX3232 circuit, there was a short of V- to ground. Fixed, it works, we have serial console.
  • Put on Ethernet wiring, works, gets 100 Mbit without problems.
  • Did all the inertial sensors and related parts (but not the filters or ADC yet), they all seem to work correctly!!!!! Unbelievable.
  • Changed the AVR ISP header to use 3V3LDO instead of 3V3, so it can program without the switching supply running (needed because the AVR has to turn the switcher on...)
  • Put on the Pressure Sensor ADCs and pressure sensors.
===4th June===
Assembly progress at the end of day one.
Enlarge
Assembly progress at the end of day one.
  • Started fitting the rest of the parts to the main board - started by populating all the parts related to the power supplies:
    • First we placed the 3.3V LDO, and associated passives. We had ordered the wrong package for the LDO, so we had to rig it up with some wire and a dodgy piece of veroboard. Will fix it when the correct package arrives. FIXME insert a photo. Anyway, it worked.
    • Placed 5V LDOs, and associated passives and power indication LEDs. Worked.
    • Placed large capacitors and inductors, switching PSU ICs and diodes. Tested 3.3V switcher. Worked. Tested 5V switcher. Worked.
    • Soldered the supervisor (AVR) and associated passives, crystal, and debug LEDs. In theory, the supervisor is now ready to start being programmed.
    • Placed the debug daughter-board connector and the passives needed for that interface.
    • Fitted the ethernet connector and associated passives.
  • Assembled the debug connector board. Started by placing the MAX3232 (TSSOP 0.5 mm pitch), then the passives, then finally the connectors and switches.
  • Assembled the GPS daughter-board. Started by soldering the GPS receiver module, then the antenna connector and finally the passives. Modified a 2.54 mm pitch right-angle pin header strip so it would fit as the connector to the main board.
===3rd June===
Reflow soldering of one of the BGA gyroscopes.
Enlarge
Reflow soldering of one of the BGA gyroscopes.
  • Soldered the three BGA parts (the Gyroscopes, see Sensors) using a toaster oven retrofitted with a temperature regulator I made.
  • Soldered the 0.5mm pitch connectors for Snapper (all 360 (total) pins by hand under a stereo microscope).
  • Used tools and facilities belonging to Bluewater Systems Ltd., and Industrial Research Ltd. - many thanks, your help is much appreciated.

2nd June

  • Added a Waypoint class to the Map application for the ground station. Wrote code to add/remove/drag around/inspect waypoints. They don't really correspond to real-world coordinates yet though. As part of this process, I redid the Map application GUI layout again, sticking with Gnome Canvas. Found limited documentation for Gnome Canvas - in Python do the following: 
import gnomecanvas
help(gnomecanvas.Canvas)
Retrieved from "http://www.albatross-uav.org/index.php/Diary_June2005"
Personal tools