+++ bookToC = false +++

7/27/2021

{{< iquestion >}}

Thank you for taking the time for this interview Kell. I know you work on robots, and teach others to do so as well, and are from the continent where everything wants to kill you, but I don't know much else: How would you describe yourself? What are you passionate about and why?

{{< /iquestion >}}

I would describe myself as an engineer, first and foremost. I put great stock in my identity as a professional problem solver, and rather view engineers and anyone who uses scientific knowledge and principles to solve problems as being the plank that stands between civilisation itself and oblivion. While that may sound melodramatic, it is because of engineers, technicians, doctors and scientists that we have medicine, power, factories, modern agriculture, and autonomy that provides for our way of life. Commensurate with that, I feel a great responsibility to use my skills and talents for good or for awesome, both to improve quality of life, reduce the impact of humanity, and to make the world a little more interesting. I'm passionate about building cool things, solving problems, advancing big cat conservation, and advocacy for LGBT* folks.

{{< iquestion >}}

What are some your favorite projects you've worked on?

{{< /iquestion >}}

By far, my favourite project is my bipedal robot. I've had a love of walking robotic war machines since I was quite young and that passion has never waned. I'm slowly putting together giant walking robot with which to crush my enemies... at 1/50th scale, due to budget limitations. As a project, it combines difficult control theory, demanding electrical design, hard mechanical design, and an absolutely horrendous integration problem. It's a hell of a challenge and I'm loving it.

{{< iquestion >}}

What part of what project has been the most difficult and/or most rewarding thing you've ever worked on?

{{< /iquestion >}}

In 2010 I co-founded a drone company developing a 25 kg fully-electric ducted fan drone for carrying a 5 kg payload for an hour. By far, that has been the most difficult work I've ever done; it pushed the very limits of what contemporary technology was capable of, and we resorted to contracting specialists in aerodynamics, materials and electrodynamics in order to make a solution happen. When it flew, it blotted out the sun, and it was terribly impressive to see overhead. Also, each prototype cost $0.25M, so you held your heart in your hand each time one left the ground. It happened to be the first time I'd managed a whole team of engineers myself, so I not only had to deal with technical challenges, but also management, logistics and ordering, which I'd never had to tackle to quite a scale before. Was it rewarding? Well, I thought it would be, right up until the company folded due to events it couldn't control. I really thought it would make me a multi-milionaire.

{{< iquestion >}}

What are some lessons you learned the hard way for how to teach engineering topics to others?

{{< /iquestion >}}

I have a list of engineering maxim's that I have slowly accumulated in my time as an engineer and educator. Every single one of them is written in blood from things that have gone wrong in the past, or challenges I've overcome. The wisdom of most of them is self-evident. Pauline's Laws:

1. Prototypes are expensive; experiments are expensive; experimental prototypes are very expensive.
2. It takes at least three prototypes.
3. The most elegant solution is often the correct one.
4. Any obvious solution to a research problem has either already been tried or isn’t a solution.
5. Simple, simple, simple; robust, robust, robust; test, test, test.
6. A good engineer is worth three ordinary engineers. A bad engineer is worth negative two engineers.
7. Be a fucking professional.
8. Engineers thrive on good management; accountants and administrators are not managers.
9. Do it right again the next time.
10. If your functional design is not sexy, it’s not functional enough.
11. Only solve one impossible problem at a time.
12. Creativity isn’t using every crayon in the box.
13. Design to build less.
    

What things to really wish other teachers would stop doing/teaching incorrectly?

{{< /iquestion >}}

There is an idea that getting students building early in their engineering degrees will get them hooked and engaged and thus improve retension and investment in their studies. While that might be true, it has the added problem that it gives students the erroneous idea that one need not think deeply or critically before designing a solution to a problem. This results in engineers whose first instinct is to start hacking away at the first approach that pops into their heads, without truly understanding the nature of the thing to be solved. There are relatively few problems that require an engineer but which do not necessitate substantial contemplation prior to crafting a solution. I see it in my fourth year design/build class. I frequently will show up to the last day of testing with a system I put together the night before, but based on all the intuition I'd gained from watching how the teams were tackling it. Very often my night-before "Dark Horse" solution will outperform the overly complicated or hacky attempts worked on for a whole semester.

{{< iquestion >}}

What languages and frameworks do you like and dislike for embedded development? Why?

{{< /iquestion >}}

I program in C because C is nice and close to the bare metal, which is crucial for dynamical control systems. I know that it lacks many of the comfortable resources and capabilities of more modern languages, but every target has a GCC compiler and almost everyone knows C. It is fairly straight forward to convert our control designs developed in Matlab M to work in C. Outside of the embedded sphere, I also code in Matlab M, as mentioned, and also Python.

{{< iquestion >}}

What technological advancements throughout your time as an engineering nerd have made the biggest difference to your everyday work? What do you miss about the "old way of doing things?"

{{< /iquestion >}}

Arguably, the advent of drones has been the largest, but only because that's my area of expertise. I have watched them evolve from being research curiosities to a whole field of study, all the way to being something you could buy off the shelf of a department store. It's great not having to hand-make rotorblades any more, but there was a meditation to it and it really made you value your vehicle to fly something where every single part was literally hand-made.

{{< iquestion >}}

Here in the states, electrical and mechanical engineering are seen as a field dominated by "Traditional Values", has that been an issue for you at all, being that you're trans?

{{< /iquestion >}}

Not in the least. I've been thrilled by the acceptance of my peers. That said, we're academics so we tend to be very progressive people who judge you on the content of your moral character and not the colour of your skin, the god you pray to, or who you love or how. Even as a professional, I don't hide being transgender, but nobody has given me any trouble to my face. It helps that I'm very good at what I do and widely respected, I guess.

{{< iquestion >}}

You've got a P.H.D, do you think pursuing that level of education is worth it?

{{< /iquestion >}}

A PhD is one of those things that people do for a variety of reasons, some more valid than others. Some people have a specific goal of being a professor, and the only way to do that is with a PhD. Others want to do the sorts of jobs that require that level of qualification (eg. nuclear systems technician, semiconductor physicist). Others still are deeply in love with their topic and find the PhD as a way of engaging with it further, on a deeper level than could be achieved in the undergrad or in industry. Some people feel obliged to get a PhD to somehow prove their intelligence, or just like the idea of having 'Dr' in front of their names, or simply had nothing better to do than continue studying. I, personally, am deeply in love with my topic (though I certainly also had something to prove), and I love the sort of work I do now - for me it was absolutely the right chioce.

{{< iquestion >}}

What very stupid mistakes do you often see very smart people make that drive you mad?

{{< /iquestion >}}

I'm surrounded by very smart people, as a matter of course, both within and outside of the university. Perhaps the key failing is in losing sight of the limits of one's own competence. If you are a smart person, you put a lot of stock in being right about things - it's probably how you earn your wage. Usually, you are certainly right about your particular topic, and very often right about topic areas surrounding it. However, it's easy to generalise that confidence in your specialisation for confidence in other areas in which you may not be fully informed. While it might sound like arrogance or hubris, really it's just a careless mistake of scope creep: without training or special grounding in a topic, one may make pronouncements on a topic with limited awareness using the same casual intuition that operates flawlessly in a domain where one has true mastery. For this reason, I very often bring up the limits of my competence as a 'ring fence' for any conversation near the edges thereof, in case I should risk crossing the border.

{{< iquestion >}}

How has the global silicon/part shortage affected you?

{{< /iquestion >}}

Frustratingly, the Bosch B**055 IMU family and ST STM32F772 microcontroller family have been difficult to source. We're buying cheap, older flight controllers to salvage parts from.

{{< iquestion >}}

What's the most important skill that you've taught yourself?

{{< /iquestion >}}

Synthetic thinking. When solving a problem, it is not enough to optimise for a single problem, a single attribute or a single parameter. For truly excellent design, you must optimise a myriad of (often conflicting) design priorities in a way that is elegant, compact, cheap, reliable and rugged. Through years of engineering and hobby design projects I have gotten very good at thinking outside the box and challenging assumptions. The most valuable part of this is to question everything you think you know about the problem, the requirements, the limitations and the goals. Push every boundary of the envelop and see what moves. Once you truly know what is important, you can often cut to the heart of the problem and attack the kernel of the underlying engineering challenge. It's rare to meet someone else who does this implicitly.

{{< iquestion >}}

Is there any skill that you spent too much time developing that you wish you hadn't?

{{< /iquestion >}}

Politics. I've been described as the best politician in the engineering faculty, and I wish I did not have to have that skill. While valuable for surviving the cut-throat academic environment, I would much rather have put those brain-cells to work finding better ways of making cars fly.

{{< iquestion >}}

What's the biggest 'Oh Shit' moment you've ever had, be it one you caught in time or not?

{{< /iquestion >}}

Well... I once destroyed a $2000 IMU from CSIRO, but I managed to get it fixed without anyone really knowing, so I don't know if that counts. I've had a few drone crashes and unscheduled disassemblies that were expensive, but not exactly disastrous. I've been blessed to avoid any truly dangerous mishaps. Perhaps the one that rises above the rest was one time at a start-up, we took 8.5 kg of lithium batteries out of storage at our workshop (which was the garage of a three story house we were renting), and they spontaneously ignited. I was asleep in an upstairs bedroom of the house when the fire alarm went off; the wife of one of the other founders alerted me that there was a fire and I ran downstairs to respond to it. Nothing puts Lipo fires out. The only solution was to open the doors to the shed, drag the batteries (which were on a carpet tile) out onto the driveway and let them smoke off. The house was undamaged by the fire, but the smoke caused a mess - it was $​50k to clean it all. However, it only occurred to me afterwards that I'd walked into a smoke-filled room with no face mask, no breathing apparatus, no training, no idea of what I was facing... I didn't realize I'd put my life on the line for it. I feel I jumped the right way, but it was a sobering thought.

{{< iquestion >}}

What do you do for fun? Any books, movies, TV shows, etc. that you'd recommend?

{{< /iquestion >}}

I engineer hobby electronic toys, particularly watches. I enjoy the works of Peter F. Hamilton, Iain M. Banks and Philip K. Dick. My favourite film is The Hunt for Red October.

{{< iquestion >}}

Who are your biggest inspirations? What creators do you think are way to underrated and deserve a shout out?

{{< /iquestion >}}

My hero and personal savior is Kelly Johnson, of Skunkworks fame. He was regarded as a brilliant 'intuitive engineer' and I'm inspired by his preparedness to cut the crap and do what it takes to solve problems and deal squarely. Nobody adequately appreciates Gustav Whitehead, Elmer Sperry, Gus Grissom, Michael Collins or John Young - the first astronaut to smuggle a sandwich into space.

{{< iquestion >}}

What's the best advice you've ever received? Worst?

{{< /iquestion >}}

The best advice I've ever received was given to me by myself: when I was feeling intimidated by what I'd have to do to get into engineering school, I told myself "don't be afraid of hard work". I realised this was a weakness of mine, and I sought to use self-discipline to turn it into a strength. I've never shirked working hard to achieve my goals. The worst advice I've ever received was "it doesn't matter what your first job out of university is - you can make your way to do whatever job you want in time". That's bullshit and I encourage anyone who receives that advice to disregard it. Life is short, and you should always be working to your goal. Even if you can't take a direct step, have a plan where each step gets you incrementally closer, and where a pathway exists between where you are now and where you want to be.

{{< iquestion >}}

What is your favorite 'hidden gem' tool?

{{< /iquestion >}}

I use an IDE called MikroC for coding PIC microcontrollers in C. It's a buggy, frustrating and awful platform, but it makes an otherwise difficult problem comparatively easy. Alas, the modern advent of HAL libraries will probably render it obsolete, but for now it's keeping me going.

My favourite hardware tool is actually a set of Align metric hex-drivers. They are convenient, ergonomic and reliable. I've used them at three different organisations on two continents, and I doubt my current set will be the last I ever own.

{{< iquestion >}}

Do you have any obscure hobbies?

{{< /iquestion >}}

I enjoy metal casting and singing opera.

{{< iquestion >}}

What hobby do you want to get into but haven't had a chance to dive into yet?

{{< /iquestion >}}

Uplift of non-sentient lifeforms. I expect I will need to crack the longevity problem before I have a chance to tackle that one, though.