Going forward (or up)

Sorry for the long pause in my blog … times are busy, and I had to put the TreppenSchlepper project dormant for months. Let's hope there is more time available during summer.

After a lot of trying and some hints from HOTINT support in Linz (thanks, anyway!) I still haven't been able to finish a first but useable version of a TreppenSchlepper model. Maybe the task is somehow a mismatch with HOTINTs original goal, or (more likely) it's me being no mechanical engineer. However, it just didn't get me to a point here the basic kinematics of TreppenSchlepper moving up a single step are simulated. So it might be time rethink strategy, better define what we need, and look for alternatives.

So, what are we looking for exactly?

In order to design a TreppenSchlepper, a model capturing its basic mechanical behavior would come in handy

Why? So we can…

1. verify a mechanical design (e.g. to check if a certain geometry and setup is safe from tipping-over going up different types of stairs)
2. calculate basic stuff like the energy required for a specific stair, as well as forces and torques to further specify the components
3. use it in a next step, to test the control software to be developed (environment identification, path planning,…)

The idea is to simulate basic static and dynamic aspects  in a mathematical simulation, which can be used to develop  the main parts (see this article) in parallel and independently, without having to invest into building up real (physical) prototypes

Maybe even a 1D simulation (z-axis) would be sufficient to get a first, rough idea. We could already use it to estimate what the (lifting) actuators need to do, and thus power consumption, timing, and energy storage requirements.

Adding a second dimension (x, z) allows to start developing the control mechanism with path planning etc.

Finally we need to go 3D, and add environment models (ground, stair), This will allow fully functional simulation of the whole system, and (together with some rendering) allow to produce nice movies.

So maybe just start over, fire up MATLAB, and start with a 1D simulation and see where we get? 

The most simple model might be comprised of just…

4 objects

That would be

• Foot_plate
• Outer_shell  (includes payload mass as well)
• Floor
• Actuator (piston between foot_plate and outer_shell)

With each part defined by its parameters (dimension, mass, potentially spring-constant)

Next, a…

Representation of the stair

is needed. While there is a great variety in stairs, they do follow a fairly common design principle, explained in the picture below.

Assuming a human step length of 63 cm, ideal stairs should be sized like this:1 x tread_depth + 2 x rise_height = step-length = 63 cm.

This is why 18/27 stairs are so common, with 18 cm rise height and 27 cm tread depth.

source: https://en.wikipedia.org/wiki/File:Stairway_Measurements.svg

Eventually we would of course need all 3 dimensions, see this blog. Might be nice to collect a small library of typical and interesting stairways which can be used to test TreppenSchlepper models and even more so its control software to come.

TreppenSchlepper Glossary & Definitions

As it turns out, names are important. So here is a first version for a glossary of the main parts of TreppenSchlepper and its environment. Basically a summary from what was done during initial model and simulation and previous posts

And while we are at summarizing: there have been also some posts (June1, June2, July, and especially Sept) addressing system control architecture, so let's depict where we've arrived so far:

Looking forward to your comments & feedback!

Simple kinematic simulation of a TreppenSchlepper

After getting in touch with HotInt (see previous post), it was time to try a little TreppenSchlepper multibody dynamics model myself. After a few hours of try & error (and a little help from HotInt support; these guys a very quick and supportive, really great!) a TreppenSchlepper model Version 0.1 was ready to be simulated. 

 Ok, even "0.1" is quite exaggerated, because it just consists of 3 parts: the FootPlate, an OuterShell and a SpringDamper in between.

The SpingDamper is just a simple substitute for the ElevatorCylinder which would be really needed, but it at least links the other two parts and provides the damper for that link. The elevation itself is currently done by a load (called ElevatingForce) defined for the z-Axis and acting on OuterShell. A Contact1D acts as coordinate constraint, making sure the OuterShell can move up but not into or below ground.  

FootPlate is fixed to ground with a RigidJoint element. The model (a text file with extension .hmc, to be fed directly into HotInt) can be found here (Filename TreppenSchlepperV0.1.hmc), while a simple up/down simulation animation is here.

The blue part (OuterShell) is modelled having a mass of 30kg , which gets lifted by a force F(t), plus gravity and spring force counter-acting.

I'm not a mechanical engineer, so if you are or know an expert: help is greatly appreciated. Just mail me at treppenschlepper@gmail.com

What could be the next steps?

1. Model a SlidingInnerShell:
   This crucial part is currently missing in the TreppenSchlepper. The SlidingInnerShell sits between the ElevatorCylinder and the OuterShell. It is needed to allow TreppenSchlepper to move forward onto the next step once it is elevated enough.
2. Model a stair
   At least a LowTread -> Rise -> HighTread for the beginning, to have something TreppenSchlepper can start to climb up
3. Model the ElevatorCylinder
   Currently it is only a SpringDamper, but eventually this should become the actuator doing the actual lifting. Probably that's a part which needs to connect to some kind of controller (to be modelled as IOModule in Hotint ?).
4. Add wheels to OuterShell
   This allows TreppenSchlepper to move on flat surfaces, like the floor, and to position itself correctly in front of a step.

As a summary, the simple TreppenSchlepper consists of

• FootPlate
• ElevatorCylinder (currently simplified with a SpringDamper)
• SlidingInnerShell (we really need that!)
• OuterShell + wheels

Then we should be able to simulate different phases during operation of TreppenSchlepper, like

#	Phase	remarks
1	move to starting position in front of step	Under control of path planning algorithm
2	Elevation
3	slide to upper level of step	actually, this will be a quite interesting phase. We need to make sure nothing gets out of balance
4	Lift, fetch and retract FootPlate

As always, comments and feedback (and help!) is appreciated, contact me treppenschlepper@gmail.com or directly via commenting this post below.

Going model-based

Why do good engineering practices often include some kind of models?

To better understand the underlying technical problems, and in order to engineer a really good design, certain aspects are typically stated in an abstracted way, a model. It allows e.g. to express, then simulate its behavior. Models provide means to explore the solution space. They help to formulate and iteratively improve the design in a virtual world, without the costs and limitations of real physical prototypes. Even better, tools exist which can more or less automatically translate the solution from the model representation to a design (code, drawings, even 3D-printed parts) for the "real world", keyword: model-based design. Good news: there were some activities started at CAMPUS02 (https://www.campus02.at/automatisierungstechnik/) by Johannes about a month ago, addressing how to express TreppenSchlepper in a model approach. We are looking forward and hope to report on results soon.

In the meantime, let's dig a bit more into modelling certain aspects.

Fortunately  there are lots of simulation tools available for domains like system architecture, physics, or software design. Some of them are free, some even in open source.

For me as an E/E engineer, the biggest question-marks in TreppenSchlepper's design lie in its mechanic. First, will it move the way we intended it to (kinematics)? What is the power, the torque required at the motors, how shall we control it? Can we be sure it will be intrinsically safe in any situation, i.e. with all the loads and dynamics involved, on challenging surfaces of stairs with a step pitch for example?  How do we determine the boundaries of such safe operation? We need this to provide the path planning of TreppenSchlepper with information ("safe envelops") so it can decide on go/no-go.

Being a layman in kinematics I turned to a web search, which brought up HOTINT from LCM (Linz Center of mechatronics), see https://www.hotint.org/.

Hotint

According to its description it is a flexible multibody system dynamics modeling and simulation tool, offered as freeware. And it integrates with another tool called X2C, which "is an open source tool for the model-based development and code generation of real time control algorithms for micro processor units" (cited from its web page http://www.mechatronic-simulation.org/x2c/x2c-home/).

So why not try it? There are even user manual and a reference manual available, although I have to admit some things became only clear after looking at the tutorials, and try and error it myself.

After spending a free afternoon with HOTINT I had my first DIY project ready, which involved 3 bodies: two masses experiencing gravity pull, hovering (at time t=0) above a third, fixed body, which should represent the step of a stair. There is a "collide"-relation called "Contact1D" between one of these masses (actually, the red box) and the stair, so while the blue body just transits through on its way down to minus infinite, the red box really bumps onto the stair and sits there. By defining material properties like spring stiffness and damping, we can simulate this bump in more detail (depth of penetration for example). Hotint allows to define "Sensors" which probe and record certain properties through simulation, like the acceleration of red box. Playing with these is fun, you can find it ("PeterTest1.hmc", done with Hotint Version 1.2.41) here.

These hmc files can be read into Hotint for simulation and visualization, or it can be used with a text editor like notepad++, with support for syntax highlighting via an extension from Hotint 

So what will come next?

It would be nice to model a simple scenario with two masses, representing the "Outer Shell" (with wheels) and the "Inner Shell" (with a lifter) of a TreppenSchlepper. Such a simplified system shall climb up one step of a stair, with the main forces/loads modeled as well. So far I'd expect to model

• gravity
• vertical lift force (between outer and inner shell)
• horizontal drive (wheels of outer shell)
• horizontal friction (between outer shell and step floor, and during lifting between inner shell and step floor)

Let's see how that works….

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.

First thoughts of a requirement engineer

So, how should TreppenSchlepper look like, what exactly should it do or provide? What are the mandatory requirements, what would be just nice to have, and what would be a killer if we forgot about it ?
The importance of good requirement engineering can hardly be overestimated, as it does a lot to define (and constrain!) the direction a project will go from then on. Even if done iteratively in an agile development process, someone better has a consistent, solid view and vision of what the system under development should look like. And defining such vision on non-functional requirements or "soft facts" might sometimes be even more important than getting all technical requirements right from the beginning.
So let's add some thoughts on the user interface (UI) and target costs.

First: do we need an UI at all? If it comes to path planning and climbing stairs, TreppenSchlepper should be fully self-controlled, thus autonomous. No human operator should be required to control its moves (please, please, no RF remote control like a toy car!). TreppenSchlepper shall detect and analyse its surroundings completely by itself, plan its path, control its movements, know when to stop, and therefore guarantee system safety at all times by itself.
However, we need a way to summon it to the place (e.g. floor number) where we want it to start, and tell it where to go (e,g, come to base floor, wait until I've placed my heavy bag, then carry it up to 2nd floor, then wait until I have recovered my bag). The obvious choice would be a smartphone app, communicating with TreppenSchlepper e.g. via BlueTooth. Is that a good idea also for people feeling uncomfortable with such gadgets? We might want to provide an alternative solution like a button on a wrist-watch (similar to the Personal Emergency Response System (PERS), but not that dramatic). Would BlueTooth provide sufficient transmission range to connect to TreppenSchlepper in a staircase, even if it is lots of floors away?  And, let's assume one wants to call (summon) TreppenSchlepper to a certain floor: we sure want it to detect automatically where to go; so how would the calling device (e.g. the smartphone) identify its current floor to send it to TreppenSchlepper (and vice versa)? Maybe a system of fixed BlueTooth stations acting both as location beacons as well as relays, forwarding calls, might help. Something like iBeacon, maybe? 


Next: Pricetag

A conventional stair lift in a museum in Berlin

TreppenSchlepper is intended to just carry things, rather then persons, at least in its initial incarnation. But it should be also much more flexible and easier to use than e.g. stairlifts, and should be more affordable as well.
According to https://en.wikipedia.org/wiki/Stairlift today's stairlifts start at 2000 - 4000 USD (and that is per floor!), even others suggest € 4.000,- to € 14.000,-,
Still keep in mind that this is for full person-carrying capacity. So I'd suggest an upper price limit for the described TreppenSchlepper of below 2000€, which might make it competititve, as this is independent of the number of floors to cover. 
Is that an achieveable price limit?                                    
                                                                                 

TreppenSchlepper System Control (1)

To be of real help, TreppenSchlepper shall be able to climb stairs and steer its way fully by itself. It needs to become an autonomous vehicle which plans, then follows its path to and along a stair fully automatically. If it assists a human user (e.g. carrying a suitcase) it shall anticipate her moves and act accordingly. Alternatively, it might be useful to have TreppenSchlepper go up or down without any accompanying person, which might be the easier option for the control algorithm to begin with.

Autonomous control shall guarantee the safety of itself as well as people and things along its way. Therefore it is required to identify passerby's or objects (like the proverbial expensive Ming vase) in advance. TreppenSchlepper needs to plan ahead its trajectory so it will not interfere with others, and to stay safe by itself at any moment. However, it might turn out that this is achievable within some restricted range only (locality), meaning that it might only be able to plan ahead within some time and spatial range due to sensory restrictions. We could well be forced to accept pre-assumptions which need to be done first, like an initial pre-scan of the whole staircase before TreppenSchlepper goes there first. This is in order to know that there really exists a safe path to go from start to destination, and that this path is reachable and usable by TreppenSchlepper. If system control finds no such path it should decide to remain at the safest place (likely the stair landing or platform ). If an unanticipated obstacles comes up (like some person just arrived, blocking TreppenSchlepper's way) it shall always be possible to pause and remain safely at its current position; of course this includes any place along its way within a flight of stairs.

So let's have a look at the inputs of TreppenSchleppers System Control

Sensors:

• Environment: TreppenSchlepper needs to scan its environment, especially shape and orientation of the steps to climb, as well as objects and persons around. It might be useful to identify some aspects of the surfaces ahead as well, e.g. if it is slippery, or fragile, or otherwise "forbidden" (thus should be avoided to be moved upon).
  While we need quite high accuracy in close vicinity (wild guess:  +/- 2mm within 1 m perimeter), we might be OK with a reduced resolution of 1cm or so for the zone beyond vicinity,  as this might be enough for trajectory planning and updating.
• Position: TreppenSchlepper needs to identify its own position within the scanned environment, especially in respect to steps of the stair currently climbed. In addition it needs to relate its position to more distinct points, e.g. to start and destination position, and other places of interest like the electrical charger station to fill up the battery when it is time.
• Orientation: this is needed in addition to position for trajectory planning. To guarantee safety, TreppenSchlepper also needs to monitor its orientation in respect to the horizontal, and react if it is askew.
• Weight: monitor weight of payload (or total weight) and stop if it gets to heavy.
• Battery state (state of charge, temperature)
• System state (temperature of E-motors, torque and wheel speed; this allows  to derive e.g. grip of wheels and detect overload conditions)