Skip to main content

Dynamic Reflection

After three years I'm leaving my engineering job at Dynamic Controls! I started as a summer intern back in 2010 and was subsequently hired as a Systems Engineer. Most of my time at Dynamic Controls was spent within the system's architecture team, designing, prototyping and specifying protocols for powered wheelchairs.

I've really enjoyed and grown in my first real world job. Dynamic was a great fledgling ground, while there I've had good mentors and great friends. One thing that stood out from the first day is the company has a strong vision of where it wants to be. The culture strongly promotes innovation, openness, sustainability and a desire for excellence. I've certainly enjoyed telling people that I help design powered wheelchairs as well!

I was very proud to be on the team that helped to design and implement the LiNX architecture. Of course there was plenty of pressure during my time as we released the first in a series of innovative wheelchair controllers. I can't wait to see a LiNX chair driving down the street knowing I helped design and program it.



The culture around learning and furthering personal development was particularly notable at Dynamic. After being exposed to a couple of the training courses I decided to run an "Introduction to Programming Course"; naturally I taught the course in Python. I took four groups of about a dozen colleagues through a twelve week course. Just before leaving I ran a condensed version of the course for our neighbours down at Allied Telesis. This emphasis on training extended to sending engineers to conferences around the country.

Dynamic Controls is increasingly embracing open source software. I took over maintenance of a useful set of internal tools that are used for talking to a Controller Area Network and after much refactoring I released the source to the world on https://bitbucket.org/hardbyte/python-can. It was very exciting to have contributors actually using the library, and even more exciting when it got forked and someone contributed an entire new backend. The suite of tools that are used internally went from only working with one hardware platform to working with a multitude.

One of earlier internal website projects that I worked on was a Requirements and Traceability tool. This PHP site was written with two other engineers and was one of the hardest database setups I've ever had to design. I never appreciated how difficult versioning of deeply linked items could be! After using this "all singing all dancing" site through one product release, we decided that the maintenance cost would just be too large so we ended up getting an off the shelf solution called Jama. After using Jama successfully for more than a year we released an open source library for interfacing with Python: https://github.com/dynamiccontrols/python-jama. It's still early days on that one, but I hope others will find it useful.

Any true reflection includes all the warts as well as the good. What hasn't been fantastic about my experience? First there were some dichotomies, it seemed very odd that a research and development department that aspires to be a center of excellence would require the use of archaic technology. Checking email was actually difficult from linux (which the entire software team use) as IMAP or POP wasn't enabled and the web client provided had stopped receiving updates sometime around Internet Explorer 5 being released. The engineering department enter their project time in a program designed for Windows 95. I don't want to start talking about the overly restrictive internet proxy.

Occasionally the bureaucracy of having to have multiple reviewers, approvers and all the various hoops that are imposed for anyone in the medical industry got annoying but I do fully understand why it is necessary.

Lastly and definitely a big positive to end on would be the fantastic people I had the opportunity to work with. I learnt so much about myself, about teamwork, and about engineering professionalism.

Its going to be a few months break now as I travel to South America with my partner Sarah. You can follow our journey with us at http://thorneynz.blogspot.com/

Popular posts from this blog

Bluetooth with Python 3.3

Since about version 3.3 Python supports Bluetooth sockets natively. To put this to the test I got hold of an iRacer from sparkfun . To send to New Zealand the cost was $60. The toy has an on-board Bluetooth radio that supports the RFCOMM transport protocol. The drive  protocol is dead easy, you send single byte instructions when a direction or speed change is required. The bytes are broken into two nibbles:  0xXY  where X is the direction and Y is the speed. For example the byte 0x16 means forwards at mid-speed. I was surprised to note the car continues carrying out the last given demand! I let pairing get dealt with by the operating system. The code to create a  Car object that is drivable over Bluetooth is very straight forward in pure Python: import socket import time class BluetoothCar : def __init__ ( self , mac_address = "00:12:05:09:98:36" ): self . socket = socket . socket ( socket . AF_BLUETOOTH , socket . SOCK_STREAM , socket .

Matplotlib in Django

The official django tutorial is very good, it stops short of displaying data with matplotlib - which could be very handy for dsp or automated testing. This is an extension to the tutorial. So first you must do the official tutorial! Complete the tutorial (as of writing this up to part 4). Adding an image to a view To start with we will take a static image from the hard drive and display it on the polls index page. Usually if it really is a static image this would be managed by the webserver eg apache. For introduction purposes we will get django to serve the static image. To do this we first need to change the template. Change the template At the moment poll_list.html probably looks something like this: <h1>Django test app - Polls</h1> {% if object_list %} <ul> {% for object in object_list %} <li><a href="/polls/{{object.id}}">{{ object.question }}</a></li> {% endfor %} </ul> {% else %} <p>No polls

Python and Gmail with IMAP

Today I had to automatically access my Gmail inbox from Python. I needed the ability to get an unread email count, the subjects of those unread emails and then download them. I found a Gmail.py library on sourceforge, but it actually opened the normal gmail webpage and site scraped the info. I wanted something much faster, luckily gmail can now be accessed with both pop and imap. After a tiny amount of research I decided imap was the better albiet slightly more difficult protocol. Enabling imap in gmail is straight forward, it was under labs. The address for gmail's imap server is: imap.gmail.com:993 Python has a library module called imaplib , we will make heavy use of that to access our emails. I'm going to assume that we have already defined two globals - username and password. To connect and login to the gmail server and select the inbox we can do: import imaplib imap_server = imaplib . IMAP4_SSL ( "imap.gmail.com" , 993 ) imap_server . login ( use