Diary May2005

From Albatross

This article is part of the diary. For all diary entries please select by month below.

2006 • August • July • June • May • April • March

31st May

• Groundstation: Re-did GUI layout for the map/editor window. Added menu, toolbar, status bar, added GUI events for all these, and removed the rulers because they are being deprecated by GTK and PyGTK. Wrote some test code for GnomeCanvas events (mouse clicks, dragging stuff round, selecting objects etc). There isn't any decent documentation for the Python bindings for GnomeCanvas, and it is starting to get very annoying. Investigated Cairo (alternate graphics engine that can be used like GnomeCanvas), but it doesn't yet seem ready for real-time interactive graphics; there are performance problems etc, and the API is not stable/complete.

30th May

• PCB Arrived from Entech Group. Woop Woop!! They gave us two copies of the main PCB, two sets of the inertial sensors daughterboards, three copies of the GPS and debug connector boards, and four copies of the Snapper/expansion connector testing breakout board.
• FIXME: John can you please put the photos of the board up.

29th May

• Groundstation:
  • Added TreeView data nodels to the information application, including sorting and searching of columns
  • Added drag-and-drop support so you can drag a flight variable from the tree view into the watch list
  • Started Map application; have a GUI prototype only. It uses a GnomeCanvas for drawing, giving us free hardware accelerated antialiased graphics, and easy pan/rotate/zoom support, while perhaps sacrificing some Windows compatibility (for the Map application only)... Update: actually, GnomeCanvas will apparently work fine under Windows.
• Sorted out how threading will work between the UDP reciever and the main processing thread.

28th May

• Started Groundstation application. Drew a GUI with Glade-2, and started writing Python code for it. See the screenshot at the bottom of the Groundstation page.
• Wrote the sending datagram and datagram packing code.
• Decided on a unified send/recieve datagram structure.

27th May

• Probed I2C lines on Snapper board to test the I2C driver; it seems to work, and does not need separate pull up resistors as suspected (they are on the Snapper board)
  • Reading and writing gives some activity on the bus, but we aren't yet sure what address and so on it is trying to communicate with
  • When the I2C driver module is inserted into the kernel (at runtime), it scans the bus for devices and seems to detect dozens of devices that don't exist. Tried to debug this problem but didn't get very far (really we need a known good device on the bus to debug it)
• Simulator:
  • Worked out the rest of the variables that need to be scraped from the simulator.
  • Decided that the simulator will take the place of the HWD. This means it will need to emit the same data as the HWD -which at this stage will be raw unscaled readings directly from the sensor?
  • This may change, it may infact be easier (less work in total) to have both the HWD and the simulator emit nicely scaled values. Shall debate this with Hugo at a later date.

25th May

• Started writing the complete list of variables that will be send between.
• Recognized that the (Python) header file creator (mkprotocol-header.py) needs a substancial rewrite. Oh well, it was just a quick and dirty hack anyway...

23rd May

• More cleanups on the datagram code
• Started writing a default daemon implementation to test send and recieve functionality.

22nd May

• Patched in the Fast Floating Point Emulator patches from http://www.mn-logistik.de/unsupported/linux-2.6/. The FastFPE worked (compile; run) and is about twice as fast as the NetWinder FPE (the default one) - from 0.37 to 0.67 MFLOPS. But the numbers produced by the benchmarks were different, indicating that it is not as accurate... needs further investigation.
• Refactored the datagram decoding code to make it more 'object orientated'
• Wrote a stub logging daemon and supervisor daemon in an attempt to sort out the most universal packet processor

21st May

• Patched in I2C support from http://www.mn-logistik.de/unsupported/linux-2.6/. It is a little old and didn't patch cleanly (had to patch some files manually, i.e. with an editor). It compiles cleanly and runs, but I don't yet know if it works until our PCB comes back and is assembled. It seems to detect a whole bunch of devices on the I2C bus on the Rig-50 development board, which aren't there. I haven't checked what the I2C pins are attached to on Rig-50.
• Tried to add MMC patch from the same site, but it failed and then didn't unpatch cleanly (i.e. more manual editing/repairs). Turns out the patch added support for MMC but the code has subsequently been integrated into the upstream kernel and was already present. Same for the CPU frequency patch (it failed and had to be manually unpatched; it is not in upstream though).
• Modified the boot scripts (/etc/init.d/) some more, and did some work on the U-Boot bootloader.
• Thinking about the architecture of the Groundstation application. I am leaning heavily towards using a number of small processes communication via UDP multicast interprocess communication (as with the on-board software). See Groundstation.

20th May

• Demoed the XScale development system to our supervisors, running Linux and communication via UDP IPC with a laptop running the simulator and UDPshell.
• Got our Snapper from Bluewater Systems, and also have (on loan) a Snapper-specific development board known as Rig-50 for initial bring-up.
• Built a Snapper Linux kernel (see Operating System for progress and more information), modified NFS-root setup for Snapper. Everything that I have tested so far seems to work. In particular however, MMC and I2C needs to be tested.
• Spent some time 'optimizing' the kernel configuration to eliminate as much unnecessary code as is reasonable. Less code == less memory, and less chance of fatal crash. The kernel is about 20% smaller now (down to 1 meg). There is probably more unnessecary code in there too.
• Wrote a spreadsheet to C Header File generator program for maintaining the list of variables and commands used for interprocess communications and calculations.

19th May

• Started ripping the appropriate state variables out of the simulator which will be necesary for SITL or HITL simulation
• Wrote peliminary datagram decoding code in C
• Started thinking about how to implement an elegant datagram/payload format which will allow easy additions to the payload/ easy additions of new variables of interest
• As a excercise I got the simulator respoing to throttle values addressed to 0x00.

18th May

• More work on the interprocess communications system (UDP multicasting, see Protocol). Have a working threaded receiver system and so on in C, as well as Albatross-protocol handling code.
• Fixed telnetd on the development board.

17th May

• Sent the PCB off for manufacturing (finally...) after some more final checking. It is expected to arrive between the 26th and 31st of May.
• Built strace for embedded Xscale Linux (works great). Investigating building GDBserver for target too.
• Worked on the initialization scripts etc and network configuration of the embedded Linux target. Rearranged some stuff to make it cleaner/tidier.
• Integrated all the libc stuff from crosstool into the new NFS root.
• Made a completely new fresh NFS root, with support from the old toolchain removed, and all binaries freshly compiled. It is about 3 meg excluding the libc libraries. The libraries are 28 meg, but many (most) of them aren't needed on a 'production' device (e.g. debugging stuff), so will be removed.
• Debated the merits of UDP multicast vs. broadcast; we both have different opinions about which is better and why...
• Experimented with threading in C (pthreads), tried to add UDP input and output to CRRCsim but it failed and was deleted again...
• Fixed the UDP multicasting code, tested on Mac OS X, Linux, and embedded XScale Linux.
• Some more kernel work; tidying up, removing unneeded options etc. Added UDP multicast support to the kernel.

16th May

• Added some global Makefiles etc, and generally fleshed out the source tree etc (include and lib directories for instance).
• Ported the UDP multicasting IPC code to C, but it doesn't quite work correctly yet...
• Wrote Python code for creating/decoding the packets for the Protocol that is used for IPC (interprocess communication) and communication to/from the Groundstation. Added check-summing (error control) etc too. Added a debugging script to UDPshell that listens for IPC packets in the Albatross Protocol and decodes, displays, and logs them.
• Investigating Simulator architecture, and the internal operation of the LaRC Sim engine (LaRCSim Architecture).
• Moved the SVN repository to http://johnstowers.no-ip.com/svn/albatross/

14th May

• Wrote UDPshell, an interactive experimentation tool for UDP communications (particularly multicasting, IPC), built on top of Python.

8th May

• Did (most of) the GPS microstrip line antenna signal routing and GPS sheilding PCB work.
• More work continuing to implement the PCB changes. PCB and schematic checking.
• Redid ethernet layout and routing after reading a few tips ([1], [2]) on improving signal integrity.

7th May

• Continuing to implement the changes to the PCB we identified yesterday.
• Decided to move the Ethernet connector off the debug breakout board and on to the main board for signal integrity reasons. Consequences:
  • pressure sensors moved futher left,
  • analog filters and yaw-rate gyro moved left and compacted,
  • complete re-routing of all the wiring for these parts of the board...
• Built U-Boot for the PXA255-Linux test system, started working out how it works and how we can use it well for Albatross. It turns out there is a (nearly-)bash-compatible shell interface in there for complex startup scripts and initialization. More proof the toolchain works (I am paranoid; ultimate test of the toolchain is the Linux kernel).

6th May

• Printed out drafts of the PCB onto paper and glued them to thin (balsa) wood sheets. Cut out, assembled them (in 3D) and checked:
  • the board fits in the box.
  • major components fit correctly, both to their footprints and with regard to spacing around them.
  • the daugher board connections and interactions work as envisioned, and still fit in the box.
• Realised more mechanical changes to the PCB are needed, including moving quite are lot of stuff round:
  • Some footprints plain wrong (D-Connector for wiring loom, GPS antenna connector, big PSU caps, big PSU inductors, radio connector)
  • Moved the pressure sensors left and down a bit, to the right of the GPS daughterboard.
  • Moved the GPS daugherboard right to the hand edge of the board (i.e. to the right of the pressure sensors).
  • Moved wiring loom D-Connector so mounting holes can be shared with radio.
• Built some benchmark programs out of interest (Dhrystone for MIPS, LINPACK benchmark for Mega-FLOPS). Get 600k D-MIPS and 0.37 MFLOPS (with the old and slow NetWinder Floating point emulator; should be able to get 2-10x better than this on our system). For comparison, my development system (P4 1.6 GHz) gets around 2000k D-MIPS and around 165 MFLOPS. Also, these tests proved the toolchain works to some degree (i.e. can build working ARM code).

5th May

• Farnell order arrived, including the much needed box.
• Measured the box and changed the mechanical shape of the board again.
• Got rid of the corner cut outs and instead put in mounting holes.
• Built Busybox for the PXA255-Linux test board, to test the toolchain and because we will be using Busybox on Albatross.
• Fixed up the U-Boot scripts for automated TFTP booting with the NFS root file system on powerup. Starting to work out U-Boot.

4th May

• Borrowed a PXA255-based Linux test board (from Bluewater Systems) to start testing the toolchain etc with.
• Got a root file system and started modifying it for Albatross.
• Setup TFTPboot and NFS-Root for the test board. Can boot a (pre-built, supplied) kernel and run with the root file system!
• Modified the boot scripts (inittab, rc.sysinit, etc.) for Albatross use and stripped out much unneeded rubbish.

3rd May

• Successfully built the Snapper PXA255 Linux toolchain (gcc-3.4.3, glibc-2.3.5, binutils-2.15) using Crosstool 0.32.
• Realised we needed some major mechanical changes to the pcb to get it to fit correctly in every dimension in the box. These changes include;
  • Making the PCB narrower by 5mm,
  • Adding corner cutouts,
  • Putting the MMC card and USB host connectors out on another expansion interface,
  • Departing from the recommend layout for PSU (by quite a lot) becuase the SMD electrolytic caps are so massive (and can't go on the back of the board)!
• Moral of the story: triple-check the board outline FIRST.

2nd May

• Continued Routing PCB: about 80% Complete, it's looking good.
• New version of Crosstool came out (0.32), started building the Snapper toolchain again (it failed with the older version).

1st May

• Continued Routing PCB.
• Decided to base the GPS decoding code on the papparazzi one, rather than gpsd, which was our first choice. The unnecessary complexity of gpsd was the deciding factor. Also, the Paparazzi code uses the U-Blox UBX binary protocol which is simpler to decode.