This articles was published on 2017-07-15
RubyOnWheelchair
Last month I gave a talk at RedDotRubyConf in Singapore with the title RubyOnWheelchair. You can see the complete talk here (for China here is the video on YouKu):
As there were several questions regarding the content I would like to address some of them here.
Hardware foundation
So what kind of hardware did I use? The wheelchair itself is from Jerry Medical and was bought straight from Taobao for ~2000RMB.
The electrical motors used inside of the chair are MY1016Z-250W24V, which is probably the most common one in China for scooters, wheelchairs and the ultra-tiny electrical vehicles which are quite popular these days. Price point for one piece is ~100RMB and a wheelchair comes with two pieces (who would have thought? :-).
The motor controller I added to drive each motor was AQMH3615NS and cost ~60RMB. I used one piece for each motor.
For prototyping the software I used a development board for the ESP32 which was ~34RMB.
Finally I ported the low-level control code to a STM32 based microcontroller board due to the reason that I want in the future to interface the low-level controller via ethernet instead of serial. This board set me back ~180RMB.
For object avoidance I used the RPLidar A1 which was ~1000RMB. This device is now legacy and the new version of it is A2.
The core of the wheelchair control was just a RaspberryPi 3 Model B which is priced these days at ~180RMB
The hardware architecture I ended up with looked like this:
Software Foundation
The main focus for me was the software part, which is heavily based on Ruby. First and foremost I used mruby directly on the ESP32 and the STM32. I have talked in 2013 about how to cross-compile and run mruby on an ARM Cortex M3.
The STM32F4, which I used, is an ARM Cortex M4, so this guide from the past is still valid today. As a matter of fact our cross-compiling toolchain of mruby improved quite a bit and today it is even easier to bring Ruby to these microcontrollers. If you are interested, have a look at mruby’s example toolchains included in our repository.
Running mruby on the ESP32 is equally simple. I was quite lucky to get some early pre-production examples of the ESP32 from Espressif in the beginning of 2016. The SDK itself had at this point many issues but it was possible for me to port mruby on it. This showed that we could finally have an ultra-low-cost MCU which runs mruby (the esp8266 is sadly to small). Since then the final production version of the ESP32 was released and the SDK became mature. YAMAMOTO Masaya and Carson McDonald made excellent progress on building a proper ESP32 mruby integration. After talking to them some time ago they even made the effort to extract a couple of great mgems (wifi, system, gpio, I2C) specially for the ESP32. I moved all my later work for the ESP32 to their codebase. Thank you guys!
The final architecture of the wheelchair looked in the end like this:
Still using MRI
Even though that every Ruby implementation works hard to become the best it can be, I always promote the idea of specializiation. mruby is not better or worse than MRI or JRuby. It is different in it’s own way and opens a new field for Ruby, which the other implementations are rightfully not adressing. During my presentation I draw the following diagram:
We can argue how accurate this picture is. For example OpenStreetMap is running on MRI and has no plan to move to JRuby and the Lidar.rb system I wrote could easily be used on mruby itself. Yet the main message I want to give out with this is, that Ruby is in an unique position by now. We have tools for very enterprisy applications. We have tools to hack away with crazy features (e.g. Refinements) and a huge amount of Rubygems for any kind of practical problems. And then we have mruby which allows us to use the same language we know so well in the embedded field, which was dominated by low-level languages before.
I don’t want to make the point that you shouldn’t mix the tools with different use-cases. Go for it and use JRuby in embedded device (e.g. Android). Go for it and use mruby for complex application setups (e.g. Container management).
The point I want to make is, that there is now such a wide and mature tooling available around Ruby that the space of use-cases which can’t be addressed with Ruby is dramatically lower than most people assume. I even claim that there is no use-case available anymore which you couldn’t solve with Ruby, yet there are good reasons to use different tools all the time. I actually use many other systems in my daily work next to Ruby! Feel free to choose, now you really have the freedom.
EveryoneOnWheelchair
The slide which gave the most mumbling during my talk was this one here:
I was hoping for a lot of resonance about this but actually after the presentation itself nobody I talked to questioned or challenged this final note. So I guess I didn’t made it clear enough or I’m just wrong in my assumption that this is the way to go. So let’s iterate about the idea one last time.
The claim during my talk was, that most involvement into the topic of accessiblity is coming from needs. If I need a wheelchair because I’m not able to move otherwise, I will invest time and money into this topic. If I’m not relying on it I will hardly think and quite likely never act on this problem. I’m a pessimist when it comes to the crowd. My conviction is, that the majority of people will not change the infrastructure around them to solve the problems of the few (even though that sooner or later they will belong to these “few”).
This is not to blame anyone but me. I also don’t believe that we can change the issue of crappy infrastructure for wheelchairs by blaming everyone who doesn’t care.
So my strategy to solve the problem is to just bring the need of proper infrastructure to everyone. By making a wheelchair which is so cool that you actually prefer to drive in it than to walk. At work I already have a setup where I sit in my wheelchair and drive between my work desk and my lab instead of walking. After having implemented the automatic path control this setup will not only be more comfortable, it will be faster (you would wonder how fast a wheelchair can drive), more efficient (having permanent power and my notebook on me all the time) and more safe (did you ever count how often you bump into someone or something when walking and staring at your phone?). Instead of promoting bicycles, segways or mini-EVs we should promote wheelchairs which don’t need power to balance themselve, which occupy only the space of one human and (most importantly) which are compatible to the needs of existing wheelchair users who might not be able to choose other means of transportation.
Wheelchair <> (Bicycle|Pedestrian|Car)
With this we come also to the conclusion that the needs of a Wheelchair are drastically different to the one’s from a Bicycle, a Pedestrian and even a Car. For example we will need different kinds of navigation:
There are a lot of challenges in actually building a wheelchair which can safely, comfortable and stylish transport people. Certainly it is more difficult than building a car which only drives on a perfect concrete path where confused pedestrians, piles of garbage, wild/domestic animals and no signage are the exception. For wheelchairs these are the norm.
So if you search for a difficult problem to solve, ignore autonomous guided cars. This problem is essentially solved. The real challenge in the AGV domain are autonomous guided wheelchairs.