Friday, September 30, 2016

Which way is up?


A few thoughts about what TreppenSchlepper needs in order to find and steer its way up a stair. Some first guess can be found in a previous post, so let's go from there.
We ask for a fully autonomous system climbing up the stair, so we probably need 4 parts:

  • Identification of the significant features  of a stair
  • Self-localization in relation to the stair
  • Path-planning
  • Steering/controlling the system along this path

Identification
TreppenSchlepper needs to identify and locate the stair, its individual steps and rises, landings between flights, also if they are curved or else special. There might be even branch-offs to  consider. And of course, TreppenSchlepper needs to know when to stop, when it has arrived at the destined floor / position.

But let's ask first: do we really need to identify the stair, steps, rises etc. "online" in order to find and control our way in real-time? Or would it be enough to do that offline once, then store some detailed map (better: model) of this environment into TreppenSchlepper, and from then on just align TreppenSchlepper's view with the stored map?
Well, this might be reasonable (and save a lot of resources) for systems which are stationary to one building. It would simplify system design, reduce computation needs, and we could probably omit some precise and expensive terrain identification sensors like LIDAR or radar or stereo cameras.
However, there might be also the need for a system which can be used at any stair and in any situation, without the need for having someone to do identification & mapping before. So let's assume a development of two versions: a simpler and cheaper Treppenschlepper which is to be used for one (or a set of) predefined stairs only, and a second, more sophisticated version able to identify and then climb any stair it approaches.
In both cases we need to represent the stairs geometry somehow. I've recently found an interesting paper describing a semantic model for stairs  [1] , a really good read. In an essence, the authors suggest to model a stair using UML and CMG, and they apply this to the task of identifying stairs from (noise, imperfect) 3D data like stereo images - just what we need.
Which leaves open two issues: which sensor, and which algorithm shall be used for identification? Well, let's keep that for another discussion.
----
[1]
Schmittwilken, J., Saatkamp, J., Forstner, W., Kolbe, T. H., & Plumer, L. (2007). A semantic model of stairs in building collars. PHOTOGRAMMETRIE FERNERKUNDUNG GEOINFORMATION, 2007(6), 415.

Localization / Positioning
In the paragraph above we've assumed there might be two versions of TreppenSchlepper, one which does environmental scanning and identification of stairs itself ("online") and a second, potentially cheaper one which already has a valid map/model of the environment stored within and just needs to locate itself in relation to that model. 
Both versions of TreppenSchlepper have in common the need to know quite precisely the own position in relation to the stair, in order to decide on path and what to do next. So self-localization (a.k.a positioning) is required. However, what localization precision shall we ask for? For example Is 1 cm enough, or 1mm?
Maybe we need both, using (i) a "raw" position in relation to the stair with 1 cm or better accuracy for path planning, and (ii) a "precise" position to exactly control its moves, in close proximity to the step. Imagine the need to sense exactly where and when TreppenSchlepper has touched the step (1mm or better).
That seems to suggest a pair (or set) of complimentary  sensors, e.g. camera and ultrasonic. We might need to fuse it into a full position information. However, let's keep sensor and algorithm question for later.


Path Planning
Similar to stair identification, there might be two classes to do the path planning:
(i) full planning, allowing TreppenSchlepper to find its way in any scenario and adapt flexibly to obstacles, or (ii) to do it once, ahead of time ("pre-planning "), e.g. by some "commissioning process". TreppenSchlepper could then move and steer along that pre-planned path. This might reduce  required computation resources in TreppenSchlepper.
However, I'd vote to implement "full planning" in any case, as TreppenSchlepper' s environment is not unlikely to change. There will be always cases with eventually moving obstacles (humans, animals) on stairs, or static objects (e.g. a bag, a vase, cleaning equipment) which were not present at pre-planning time, which will make it necessary to adapt and re-plan the path.
Full planning is what we want in TreppenSchlepper; an interesting topic for some of the next blogs. It shall not only include the finding of a valid and safe path, but also how to go towards any optimal path etc.
And let's not forget about another important safety aspect: if path planning finds out that there is no safe path it needs to stop TreppenSchlepper (even better: prevent it from starting in the first place)!

Steering/controlling
Finally, with a valid planned path available in memory, system control "just" needs to steer TreppenSchlepper along that path. I hope classic control theory will come handy for this. However, it would also need to adhere to a set of conditions and boundaries, like safety (avoid certain locations and moves), robustness including failsafe-ness (TreppenSchlepper should be in a stable, static position at any time, e.g. in case it has to shut down suddenly). It needs to take care of safe operational area of its components (E-motors, converters, battery), and generally work as efficient as possible to conserve energy stored in batteries.