About Me

From a farming community in Australia, but living in one of the biggest cities in Asia. Trained as a theoretical mathematician, but working far closer to the real world as an engineer. Competed at a semi-professional sports level, but at the same time, very academic oriented.

The dichotomy of who I was used to bother me especially as I strove to become what was expected, an expert. Instead I kept plummeting through a causal chain of events that required reaching out in different directions to break down walls. Though I didn't start in the field, robotics has turned out to be a good match since it is such a melting pot of technologies, ideas and people and ultimately, everything that has gone before has been very useful in creating an interesting path for my career to follow. At the end of the day, I enjoy challenges that reside in the space where algorithms, programming, technology and people converge on the real world. 

Over the last few years I've worked across robotics projects in the capacity of an algorithms developer or programmer, spanning from academia to almost product and back again.  

The last position, leading the innovation team, is what I've enjoyed the most. It has a sense of connectedness everywhere - to the ideas born in academia, with the investors that make it life and death, and the elderly care resident who starts seeing and interacting with a portion of what you are bringing.

This is where all of the background pieces fall together. They let me engage effectively with anyone in the process - from the researcher through to the user. The primary challenge over the last few years has been to work out where to stop challenging myself and instead become the catalyst or facilitator for others so that we can solve the greater challenges together.

Where to Next?

I would prefer to continue working in an environment that allows me to engage at many levels. This could be with an innovation team again, or as a software lead/architect for a larger project. Having said that, falling back to a algorithms/lead developer role would not be undesirable. There are altogether far too many interesting challenges around, especially in the field of robotics and computer science!

The Software Vertical

While most software groups and companies exist in the horizontal, building a robotic system often requires encompassing the vertical. This will hopefully change in the future as the ecosystem matures and different groups are able to provide at different levels, however right now there are many holes that need filling. The table below shows where I've filled holes - green indicates that I've been a core developer or directly supervised, blue where I've simply developed, or supervised another team handling the details and yellow where I've had minimal experience.

My development experiences can be gleaned from the product and project sections in this portfolio.

My supervising experiences emerged from situations where I unofficially stepped into a capacity of team or project lead simply to fill needs that weren't being met (e.g. first iteration of cleaning robot software, kobuki, ...) or as a mentor when no other expert was available. These culminated in an official role when we formed the innovation team at Yujin. The team in particular has many young people who need mentoring and a couple of experts who dive deep, but need to be aligned with a bigger picture that is often outside their box. In most cases, each one is on their own - the team is not large enough or experienced enough to accommodate enough overlap between employees to help each other usefully.  Here I have been a facilitator to aid in mentoring, designing, reviewing and building bridges so that the big picture comes together.

Some more interesting adventures include introducing ROS control developers to the idea of stateless request/response systems from the web world, and convincing web developers that pub/sub does not mean the end of the world either. Being able to guide an expert in distributed scheduling systems to understand that the needs of distributed service robotics has subtle, but significantly different demands to that of distributed job handling in the cloud. Simply knowing enough about programming beyond robots to engage in discussions with those who have a much more rigorous background in computer science has been essential in order to pull them more usefully into the project. Knowing enough about the research behind navigation planners to guide a young masters student towards a full implementation on the product or to align an embedded vision slam expert on the cleaning robot with a problem far less constrained on a ROS based service robot usefully. At a lower level, being able to train a firmware engineer to start working at the driver level and engage with him intelligently on the problem of getting firmware and driver to work together in the most useful way possible. At a higher level, I've not directly supervised our young web team, but have been regularly working with them at a higher level and advisor when it's been obvious they are struggling with typical long term programming problems - dependencies, planning, directional decision making and also to co-ordinate the development of REST API specifications between the robot and web teams.

There is a great many flavours of people and styles within software world alone. It is interesting to see different patterns emerge that can be useful elsewhere and to solve the jigsaw puzzle to bring it together.

Open Source

History

TODO :

ROS

TODO :

Innovation Team

My roles in Yujin's Innovation team (2013-16) were about building and directing a young team, software and technology lead, service design, collaboration across both internal and external teams and to a smaller extent, the business development.

• Dissatisfied with the conflicts arising from a blur between innovation and product development
• Pitched the idea of an innovation team to the CEO/CTO
• Formed the group with co-leader Marcus Liebhardt who would focus on product management
• Hired a business developer to immediately start exploring options
• Explored several disruptive (but longer term) business models with partners
• Kept getting pushed towards logistics
• Migrated Yujin's localisation technologies from cleaning robot to a more difficult use case
• Started growing the team to 11 by 2016 with extra help from two other small internal teams
• Pushed to differentiate from emerging logistics groups with more accelerated funding plans
• Differentiated around vision slam/reduced wifi dependency for more unstructured environments
• Targeting smaller, older hospitals and elderly care
• Several successful field tests in 2016
• Concluded with interested parties at the table with Yujin
• Transfer to Yujin's product groups in 2017

Korea

Korean people are wonderful. They are by and large, exceedingly tolerant and wonderfully nice. To be able to walk anywhere in a sprawling metropolis the size of Seoul and not be worried for your safety is absolutely incredible. To see kids actually know they can put their trust in an adult is unimaginable. It is perhaps like rewinding our society and oft makes me feel our society is in many ways dysfunctional.

Working in Korea, however, is the flip side of the coin. On a technical side, working with Software groups has been a struggle (hardware is no problem). They lag behind since they are unable to immerse themselves in the rapid change that sees the rest of the world accelerate much faster than one country can do alone. Their workflows also pose problems when it comes to handling complexity. Integrating with the Korean System has also been difficult. Thought processes are more often than not orthogonal, and hierarchical information flows raise many stubborn barriers. These things I've seen drive many foreigners stir crazy, but technical lag and bureaucratic stubbornness are actually the same problems you'll find anywhere, to a varying degree.

While working at Yujin, I had many incremental successes, though never as fast as I would like! In general, it was about finding a valuable key to unlock, or by example until the benefits were too obvious to ignore.

Cycling

Perhaps strange to put here, but it was a key part of my life for a long time and especially so during the course of my PhD where for quite some time there was just the books and the bike. 

I started in triathlons and then switched to racing competitively on track and road until I hung up the boots when I came to Korea ... to focus on my career. I miss the racing, but there are far more real and interesting challenges in life that can replace that. In hindsight, what I most miss is the outdoors and the wonderful spectrum of people you meet and get to know intimately while sharing many hours on the road together. There is the curiosity in watching what makes the elite tick - I was lucky to race head to head with guys who were/would go on to become pros, world junior champions and even world track champions. However, there was also the farmer with too much imagination to stay stuck on the farm all day, the juniors vacillating between wanting to become a world champion and just a kid, the brickie who needed some fire in his life and the big fellow who just needed to get whatever it was in his system all out on race day each Saturday.

I still ride, to stay fit and keep my sanity, but I've not had the time with my job and a young family to be able to pursue such a lifestyle since and as such, the world seems to lack a little flavour without these guys and girls around.

Products

Gophers

TODO :

Kobuki

• When: 2012-2016
• About: research platform designed to connect Yujin with the robotics community
• Role: project lead from 2012-2014, support thereafter
• Areas: project management, software, turtlebot software lead

Kobuki started as an idea to attract young korean roboticists to Yujin, pre-trained on a platform similar to their products. This however, quickly scaled up to an international release after a connection with Willow was made to create the Turtlebot 2. Compared to the cleaning robot, this was never going to be a core product, but given the cleaning robot was already mass produced with strong QA assurances, it would have been a missed opportunity not to take advantage of it.

I started out providing the idea and the connection to Willow, but quickly had to step into the project lead role to drive it. Being responsible for a project which was not the core focus for many of the groups involved, but requiring the assistance of those groups (sometimes reluctantly) was a bumpy ride with many learning experiences. Kobuki went on to sell close to 10,000 robots in this period and more than managed to return investment costs whilst also being the catalyst for new recruits.

I was also responsible for upgrading and maintaining the Turtlebot software in this period, especially during the migration from Willow to OSRF.

Once released (2013), I was reluctant to re-enter management, especially in the province of making promises I could not deliver because of groups at the periphery of my working sphere. I've since come to appreciate that this is exactly part and parcel of managing expectations as a manager. It is the groundwork required to understand the groups and the technology you work with, the risks and sometimes exposing that analysis, that is paramount to making those promises real for you and for the party on the other side.

Cleaning Robot

• When: 2009-2010
• About: incubation project with Phillips, from research to product
  
• Role: push the software technology forward after it started stalling too early
• Areas: vision slam, build system, black box bug fixing , overall performance

I came into this project midway, just as the flurry of features was slowing down due to a rising expectation to make sure new features did not cause regressions elsewhere in the (partially) working product. With a growing number of testers/observers from both Yujin and Phillips closely watching progress, this started causing the development to stall before the requirements for a minimal viable product were being met. My roles involved optimising and extending the slam to handle extreme environments (either too feature-rich, such as a bookcase, as well as feature sparse), identifying and dealing with sources of hardware variance (camera and gyro), deep bugfixing, and a swathe of software development practices to an embedded team's monolothic application approach. This included revamping the build system to speed their builds by 10x, teaching them how to remote gdb debugging, writing tools to enable remote gui monitoring and breaking up their application into a suite of libraries that could be natively compiled with tests to track down the most difficult bugs.

I suspect being an outsider helped in pushing this project forward in terms of being able to provide feedback in ways that some of my Korean colleagues could not. It was also a period of rapid change in the company - solutions in high pressure situations will always do that.

One of the most enjoyable journeys of this project was to watch the slam progress from being able to navigate the lab, then the CEO's room, then an assortment of regular homes in Korea and finally the very difficult homes of the Phillips executives in the Netherlands. Each one, a seemingly impossible obstacle when we started! Once we crossed the line, I realised I was enjoying my career in a company more than I had in academia.

Various Government Projects

TODO :

Projects

This is a very short list of some of the programming projects I've worked on. While they're not all sexy, they do provide reasonable coverage with respect to the kinds of projects that I have worked on. They are sequenced roughly according to the date that I started becoming heavily involved in each area.

TODO : TIMELINE PIC

Py Trees

• When: 2015
• Purpose: decision making inside the robot
• Language: python
• Core Library: https://github.com/stonier/py_trees_suite 
• Monitoring & Playback: https://github.com/stonier/rqt_py_trees 

This was motivated by a need to find something simple to handle the decision making logic inside the robots and yet not be wired down in another state machine implementation that gaming experts warn against. Unfortunately, there are next to no (decently) open implementations around and as it turns out, gaming companies mostly roll their own and keep it in house. So, we tentatively embarked on yet another in-house implementation and became surprised at just how easy and flexible the approach became, for both developers and users of the libraries. So much so, that almost all of the robot's decision making quickly centralised in the behaviour trees.

• Python for rapid development
• Anything requiring reactive speed kept outside of the behaviour trees
• All other decision making...in
• Interested in the power user case - discussion about gui's for behaviour tree creation shelved
• Focus on flexible behaviour creation and reuse
• Focus on runtime bagging of behaviour tree changes and offline replayability
• Focus on runtime monitoring with useful debug/diagnostic expressiveness
• Takes advantage of python generators to efficiently crawl a large tree
• Takes advantage of python decorators to create common behaviour customisations
  • e.g. running is failure

Currently not yet officially released (though open). Requires tutorials, documentation and a reference example in simulation before committing to a proper release. Heavily used internally now at Yujin.

Navigation Stack

TODO :

Multi-Robot

TODO :

Vision Slam

TODO :

ECL

• When: 2007-2010
• Purpose: cross-platform boost like layer of libraries usable on very embedded targets
• Language: c++
• Wiki: http://wiki.ros.org/ecl
• Github: ecl_tools, ecl_lite, ecl_core, ecl_manipulation
• Doxygen Sample: ecl_manipulators

The embedded control libraries were my first effort at writing an extensive set of c++ libraries. These were initially required to provide a suite of c++ tools that could abstract out the posix/win32 requirements on different robots at the company. This included the cleaning robots, for which Boost was not an option. It also got extended to provide many additional (fundamental) tools that could be shared across projects. One example is the manipulators library (doxygen) which provides classes and algorithms to enable joint based trajectory interpolations. One of these algorithms is entirely new. The tension spline interpolations, guarantees more controllable smoothness and boundedness characteristics of the acceleration profiles which was essential when working with manipulators of low cost/quality.

The libraries make extensive use of templates and meta-programming which were employed (mostly) as a learning experience for myself. In hindsight, this was a mistake. Getting traction with respect to usage across the teams was not a problem, however this did raise a considerable barrier to contributions from other developers who needed to contribute, but did not have the requisite level of skill and inevitably fled from the first sight of a curiously recurring template pattern.

The libraries haven't changed much in recent years, but are still used quite extensively in the company and Kobuki, even though large parts of it have been made redundant by the arrival of c++11.

Build Systems/CI/Devops

• When: 2007-2016
• Purpose: tools, as needed, to ensure a robotics team can focus on robotics
• Tools: ament, ansible, apt-repos, autools, buildbot, catkin, cmake, docker, jenkins, travis

I've invested far too much time in build systems and continuous integration/devops than I ought to have done and should have pushed more strongly to hire someone in many situations. As a result, I've felt the need to express myself similarly to Bones above, but in a wry, sarcastic manner to suggest I need to get back to developing. Unfortunately, it is often part and parcel of working with a small group that has limited resources and few with the skills/knowledge/desire to solve the problems that the project as a whole require to be solved. This started with watching every member of the cleaning robot team spending 10+ minutes cleaning and then fully compiling their application on a virtual machine every time they touched the code. Nine years later, it is hard to believe a group would do this. I've since built tools and transferred the expertise for building toolchains, cross-compiling, library management, native and cross-compiled test suites in such a way so that team now only requires one person to have the knowledge while the rest of the team can get on with their jobs. Over the years and for other teams I've been responsible for, or delegated the work to build up processes and practices to handle continuous integration, releases, staging environments, third party deb support, docker builds and an ansible framework so that a robotics team can focus on what they are meant to do...robotics!

I've also been drawn into processes to upgrade ROS so that workarounds are not needed for building on a variety of platforms.

IMU & Control Firmware

TODO :

PhD

Stability Theory and Numerical Analysis of Non-Autonomous Dynamical Systems

• PDF - no pictures

• PS - with pictures

The thesis started out as an unfruitful exploration into various hoped for characteristics in co-cycles and then shifted into investigating concepts in non-autonomous systems around pullback attraction for which there were already several preliminary results. The key point here being to look at the convergence to a particular point (or set) in time as one pulls back the initial point (set). That is, if you start playing the piano early enough, can you guarantee that a grand pianist will emerge at the age of 20?

For most examples it might seem that pullback attraction does not offer anything new. However the pianist analogy rings true here. While you may get a grand pianist at 20 if you start early enough, your are most certainly unlikely to get a grand pianist at age 80, even though the person may have trained for 3-4 times as long throughout their lifetime. 

The foremost contribution of the thesis was to correct, extend and integrate the concepts of pullback theory with the conventional notions of stability and attraction in non-autonomous systems. It then proceeded to develop a Lyapunov-like theory which operated on states of pullback/forward/complete stability and attraction. It also proceeded to investigate the ramifications of discretisation on systems with known pullback/forward/complete stability characteristics.

The PhD itself took a long and circuitous route. The state of mathematics in Australia at the time was considerably unstable, with entire departments being closed down and ours no exception. I was fortunate enough in having my supervisor be able to take me with him to Germany for one year before eventually returning to Australia and working on the remainder remotely. While this was not easy, it did prepare me with a solid theoretical grounding and a confidence to push through barriers on my own.