University of Twente

EEMCS / Electrical Engineering

Control Engineering

Model-based redesign of a self-balancing scooter

Teun van Kuppeveld

MSc Report

Supervisors: prof.dr.ir. J. van Amerongen dr.ir. J.F. Broenink ir. M.A. Groothuis dr.ir. A.M. Bos August 2007 Report nr. 022CE2007 Control Engineering EE-Math-CS University of Twente P.O.Box 217 7500 AE Enschede The Netherlands

Summary
Mechatronic embedded systems designers innovate to stay ahead of the competition. Reduction of development costs and design time are potential areas for optimization in system design. ViewCorrect is a project that aims to improve the development method for mechatronic embedded systems. During the ViewCorrect project various test cases are foreseen to evaluate its results. For the participating companies these test cases will also be used for evaluation of the methodology. This document reports about one of the test cases: The self-balancing scooter. Requirements for this project are the use of brushless DC motors, only one accelerometer may be used and the embedded controller software needs to be implemented in hardware(FPGA). For this test case, the ViewCorrect design trajectory is used. So the test case began with modeling the physical dynamics of the setup, and followed by control law design. When the controller was ready, the next step was to implement the embedded control system. With this step the model was extended with the properties of the electronic hardware. Due to the fact that the controller needs to be implemented in a FPGA, the controller needs to be rewritten to a discrete controller. The last step is the realization of the system. Every step uses simulations for verification. During this trajectory design space exploration was used to be able to make design choices in an earlier stage of the design of the system. From the execution of the project the following lessons are learned: More interaction between the designers of the different disciplines is realised. Software integration on hardware not possible to implement in core model. Interface specification is required. Usage of core model leads to common understanding of system behavior. Possibility of virtual prototyping.

For the design of a self-balancing scooter the following conclusions can be made. The project resulted in a simulation model of the scooter which is able to simulate the behavior of the scooter. The acceleration sensor is not accurate enough for this project. The use of a gyroscope needs to be investigated. For ViewCorrect the following conclusions are formed. The ViewCorrect method reduces the distance between the disciplines and introduces more teamwork. With the core models a common understanding of the project is realized. The design becomes more accurate. Recommendations for the self-balancing scooter as already said is the introduction of the gyroscope and besides that the control for the operator needs to be investigated. Recommendations for ViewCorrect are the extension of the method with a process. During the design trajectory interdisciplinary meetings are required. Besides this point also additional tooling needs to be realized.

Control Engineering

ii

Model-based redesign of a self-balancing scooter

Samenvatting
Vernieuwingen in de ontwikkeling van mechatronische embedded systemen is nodig om de concurrentie voor te blijven. De vermindering van ontwikkelingskosten en de ontwerptijd zijn potentile gebieden voor optimalisering in systeemontwerp. ViewCorrect is een project dat de ontwikkelingsmethode voor mechatronic embedded systemen wil verbeteren. Tijdens het ViewCorrect project zijn diverse test cases voorzien om de resultaten van het ViewCorrect project te evalueren. Voor de deelnemende bedrijven zal deze test cases ook gebruikt worden voor evaluatie van de methodologie. Dit verslag zal een beschrijving geven van n van deze test cases: de ontwikkeling van een selfbalancing scooter. Naast de keus voor een self-balancing scooter zijn er ook nog andere vereisten gentroduceerd voor meer uitdaging. De vereisten voor dit project zijn het gebruik maken van brushless DC motoren, maximaal n versnellingsmeter mag worden gebruikt en de controller moet volledig in hardware (FPGA) worden uitgevoerd. Voor deze testcase wordt de ViewCorrect design trajectory gebruikt. De testcase begint met de modellering van de het dynamische gedrag van de opstelling. Dit zal met een ontwerp van de regel wet worden gevolgd. Wanneer de regel wet ontworpen is, is de volgende stap het embedded control system te implementeren. Met deze stap zal het model met de eigenschappen van de elektronische hardware worden uitgebreid. Vanwege het feit dat de controler software in een FPGA moet worden geimplementeerd, moet de controller ook worden omgeschreven naar een discrete controller. De laatste stap is de realisatie van het systeem. Tijdens deze stappen zal simulatie worden gebruikt om te controlleren of het gewenste resultaat wordt behaald. Tijdens de design trajectory wordt er gebruik gemaakt van design space exploration. Dit moet er voor zorgen dat er in een vroeg stadium al belangrijke design besluiten kunnen worden genomen. Aan het einde van dit project kunnen we de volgende conclusies worden getrokken: Meer interactie tussen de ontwerpers van de verschillende disciplines is gerealiseerd De integratie stap tussen hardware en software kan niet worden geintegreerd in het core model. Specificatie van de interfaces is vereist. Het gebruik van de core model leidt tot een gemeenschappelijk begrip van het systeemgedrag. Introductie van het virtueel prototypen.

Voor het onderdeel van de self-balancing scooter zijn de volgende conclusies getrokken. Het project resulteerde in een simulatiemodel van scooter die het gedrag van scooter kan simuleren. De versnellingssensor is niet nauwkeurig genoeg voor dit project. Het gebruik van een gyroscoop moet worden onderzocht. Voor ViewCorrect kunnen de volgende conclusies worden getrokken. De methode ViewCorrect vermindert de afstand tussen de disciplines en introduceert meer team werk. Met de core models wordt een gemeenschappelijk inzicht in het project gerealiseerd. Het ontwerp wordt nauwkeuriger. De aanbevelingen voor de self-balancing scooter zoals reeds gezegd is de introductie van de gyroscoop en naast dat moet de controle voor de bestuurder worden onderzocht. De aanbevelingen voor ViewCorrect zijn de uitbreiding van de methode met een proces. Tijdens de design trajectory worden interdisciplinaire vergaderingen vereist. Naast dit punt moeten ook extra softwarematige hulpmiddelen worden gerealiseerd

University of Twente

iii

Contents
Introduction ......................................................................................................................................1 1.1 Context....................................................................................................................................1 1.2 Aim of the project ...................................................................................................................1 1.3 Approach.................................................................................................................................1 1.4 Structure of the report .............................................................................................................2 2 Background ......................................................................................................................................3 2.1 ViewCorrect............................................................................................................................3 2.2 Design trajectory.....................................................................................................................4 3 Redesign of the Self-balancing scooter ............................................................................................7 3.1 Physical system modeling.......................................................................................................7 3.2 Control law design ................................................................................................................10 3.3 Embedded control system implementation...........................................................................12 3.4 Embedded Control Software Realization and Integration ....................................................14 4 ViewCorrect evaluated ...................................................................................................................15 5 Conclusions and Recommendations...............................................................................................17 5.1 Conclusions...........................................................................................................................17 5.1.1 Self-balancing scooter ......................................................................................................17 5.1.2 ViewCorrect .....................................................................................................................17 5.2 Recommendations.................................................................................................................17 5.2.1 Self-balancing scooter ......................................................................................................17 5.2.2 ViewCorrect .....................................................................................................................17 Appendix A Bond graphs....................................................................................................................19 Appendix B Rigid Bodies ...................................................................................................................23 Rigid body..........................................................................................................................................23 The self-balancing scooter in rigid body notation..............................................................................25 Appendix C Model of the mechatronic self-balancing scooter ...........................................................29 Model self-balancing scooter .............................................................................................................29 Discrete vs. Continuous......................................................................................................................30 Appendix D Simulation results ...........................................................................................................33 Design space exploration ...................................................................................................................33 Working of the sensor ....................................................................................................................33 The sampling frequency .................................................................................................................35 Motor power...................................................................................................................................37 Sil Simulation.....................................................................................................................................38 Literature ................................................................................................................................................41 1

Control Engineering

iv

Model-based redesign of a self-balancing scooter

University of Twente

1 Introduction
1.1 Context

Mechatronic embedded systems designers innovate to stay ahead of the competition. Reduction of development costs and design time are potential areas for optimization in system design. Research is ongoing on improving the development methods for mechatronic embedded systems; the ViewCorrect project is one of these. The research funded by STW program PROGRESS (PROGRESS, 2007), is done by a collaboration of the Control engineering group at the University of Twente (CE, 2007), the Electronic System group at the TU Eindhoven (ICS/ES-EE, 2007) and the companies Oc (Oc, 2007) and Chess (Chess, 2007). Chess is a company, which develops high-tech products, from chip to internet solutions. One of the business lines within Chess develops advanced software and hardware for embedded systems.

1.2

Aim of the project

The research described in this report is an example test case by Chess for the ViewCorrect project. The ViewCorrect perspective is to evaluate whether the ViewCorrect design approach is an improvement of mechatronic system design. The main reason for Chess to participate is their interest in model-based design. Chess vision is that model based design enables Chess to better understand the customers problem domain to stimulate the creative process to create better products in a shorter time. This test case provides for Chess the possibility to evaluate the methodology. The goals of the project are the evaluation of the ViewCorrect methodology in an industrial project and the redesign of the self-balancing scooter.

1.3

Approach

The test case deals with the redesign of a self-balancing scooter, as shown in Figure 1. For this test case, a self-balancing scooter was chosen because it is an instable system with nice control challenges. Because of the properties of the system, a good and structured way of designing the controller is needed to come to a good result. Besides this point also other challenges were introduced as requirements: The use of Brushless DC (BLDC) motors instead of the often used brushed DC motors. Only one accelerometer may be used to control stability. No gyroscopic sensor is allowed. The controller will not be implemented on common off-the-shelf (COTS) motor controllers, but fully implemented in configurable hardware (FPGA) to allow full control over the control loop. Certain motor controller units have built-in controllers without the possibility to get full control on its parameters and properties.

Control Engineering

Model-based redesign of a self-balancing scooter

Figure 1 A self-balancing scooter An initial prototype was implemented before the start of this project and showed limited stability of the scooter when using the single accelerometer and a COTS BLDC controller. In this MSc project the self-balancing scooter is redesigned but then with the use of the ViewCorrect design trajectory. (See Chapter 2 for more details). The design trajectory uses a structured iterative way of designing the embedded control software of a mechatronic embedded system. The design is done in several stages; physical system modeling, control law design, embedded control system implementation and realization. Each stage also includes verification with the use of simulations. The end of the test case is concluded with a discussion on the design method, keeping in mind the ideas behind ViewCorrect. The design trajectory yields the following models of the system: Of the dynamics of the electro-mechanical part Of the control system Of the digital control electronics

The last step of the trajectory is the implementation of controller software. The models are used to validate the concept of the mechatronic embedded system. During the design of control software for the self-balancing scooter the electronic hardware of the step is also redesigned. Due to this redesign the ViewCorrect method is also tested for cooperation of people from different disciplines.

1.4

Structure of the report

More information about the background of the project is given in chapter 2. Chapter 3, gives a description about the test case. Attention is given to experiments with the model and to validations after each design phase. Chapter 4 describes the conclusions for ViewCorrect on the test case. Detailed descriptions of the model and simulations are documented in appendices A, B, C and D.

University of Twente

2 Background
2.1 ViewCorrect

The ViewCorrect project is a research project dealing with the development of a new methodology and support tools for the development of distributed hard real time embedded control systems for mechatronic products. The goal of the ViewCorrect project is to obtain a reduction in design time and costs with the use of an improved design methodology including support tools. In the project description of ViewCorrect (Broenink, 2005) an idea is proposed to obtain these goals. In this idea three points of attention are used. The following points of attention are used in the project: Views. Multidisciplinary core models. Correctness preserving code generation. The idea is to reduce the distance and tension between the different disciplines that are needed during a design of a mechatronic system. The subject view in this research stand for the different view that each discipline has in the design of a mechatronic system. During the design of a system these disciplines work on their own subject, without knowing what result of design decision might have on another design discipline. Each discipline uses its own way of designing and also their own familiar tools. A consequence of this is that it is hard to reduce the distance or the tension between the various disciplines. Multidisciplinary core models are the following subject in the ViewCorrect project. With the use of multidisciplinary core models, a link between the views of each discipline can be constructed, shown in Figure 2. With this link the distance and tension between the various disciplines can be reduced.
View / Edit View / Edit View / Edit

Automatic Control View

Dynamic View

Computer Hardware View

Discrete Event View

Robustness View

Reliability View

Multidisciplinary Core models

3 Embedded Target Platform

Co-simulation Verification 2 Consistency check

Figure 2 Multidisciplinary core models A multidisciplinary core model is in the best case a unifying semantic model, but in ViewCorrect a core model is a more standard model. For example this can be a time-continuous or a time-discrete model. Co-simulation is used to interact between the different models and tools of the different disciplines. The co-simulation immediately demonstrates the impact of design decisions made in each discipline of the design. This introduces an early integration of the different disciplines and reduces complex system integration problems at the end of the project. Also the early integration at model level makes it possible to test the system without having a physical prototype system available (virtual prototyping). With this advantage the project team can work closer together and work better as a team. Control Engineering

Model-based redesign of a self-balancing scooter

The team work can be seen in that the knowledge of the different disciplines is easier used in other disciplines due the core models. With co-simulation each discipline stay using its own tool instead of the need for the introduction of a new tool. This reduces the difficulties of learning and understanding the new methodology. Besides the coupling of the views with the core models, correctness preserving code generation is a research topic. This means that with the use of the models that are validated in co-simulation the code for the embedded control system can be generated. Now with the use of the core models it has become easier to generate code, because the different models are coupled. Due to this co-simulation also the hardware design decisions can be taken into account. This can reduce the difficulties in the end of the project, where different signals are used in simulations as in the real setup. The ViewCorrect project is summarized in Figure 3. With the use of the integrated models, also called core models, the views are working closer together and the automatic software generation is simplified. As a result design time and design cost will reduce. Requirements design time
Integrated models

Requirements

design

disciplines tension Final test & Integration Realisation: reliable & robust

design

disciplines
Final test & Integration

Realisation: reliable & robust

Figure 3 Common practice (left) versus integrated design trajectory (right)

2.2

Design trajectory

The development of real time embedded control systems follows the design trajectory (Broenink and Hilderink, 2001). This trajectory is schematically shown in Figure 4.
Physical System Modeling Control Law Design
Embedded System Implementation

Realization

Verification by Simulation

Verification by Simulation

Verification by Simulation

Validation and Testing

Figure 4 The design trajectory The design trajectory represents four stages: Physical system modeling, Control law design, Embedded control system implementation Realization. University of Twente

Background

The design is done in a stepwise refinement process. Each step includes verification of the results with the use of simulation and the last step ends with testing the setup. The verification is done to make sure the design criteria are met. In the first stage, the dynamic behavior of the system is modeled. The dynamic behavior can be illustrated with the use of e.g. mathematical equations or bond graphs. This is needed to get a clear view on how the real setup will react in certain situations. A control law is designed in the second step, by using the resulting model of the first stage. In mechatronic system, control laws are needed to guarantee the working of the system as is intended. A controller can also be used to improve the performance of the system. The control laws are implemented in control software using the third stage. The code is optimized for the ECS hardware used in the system. The generated code also can be verified using simulation, before the implementation in the real setup. When the controller software for the embedded system is ready, implementation on the hardware can be realized. The code of the control laws are implemented on the real system. After the realization the setup is tested. The setup is tested whether the requirements of the system are satisfied. Also validation of the model is done after the realization step. The end result after the trajectory should be a working step. With multiple iterations each step can be refined and optimized till the desired result is reached. The first iteration can be done with a simplified model, for example, and can be extended with more details during the further iteration steps towards the final result. During this MSc project design space exploration is used. Design space exploration evaluates certain variants of implementations during the design of embedded systems. Through each step, from the idea to the realization, of designing a mechatronic embedded system design decisions are made. With this design decisions the design becomes more and more detailed which results in fewer possibilities in the end. This is also shown in Figure 5. Point X in the figure shows the position of a design decision, this results in a smaller design space at position Y. Idea Requirements Abstraction level X Specification Architecture Implementation Realization Solution Construct aspect models and evaluate properties

Figure 5 Design pyramid, showing different abstraction levels (Corporaal, 2006) With the use of design space exploration more design decisions can be taken early in the project. With the use of simulations it is possible to test more variations. For example questions can be answered on which sensors or actuators are required, where the sensors need to be placed, etc. The used design trajectory, explained above, needed to be extended to introduce design space exploration. The extended design trajectory can be seen in Figure 6. Design space exploration takes place with the simulation needed for verification. With the use of simulations various variants can be tested and choices can be made according the outcome of the simulation results.

Control Engineering

Model-based redesign of a self-balancing scooter

Physical System Modeling

Control Law Design

Embedded System Implementation

Realization and integration

Verification and design space exploration by Simulation

Verification and design space exploration by Simulation

Verification and design space exploration by Simulation

Validation and Testing

Figure 6 Extended design trajectory

University of Twente

3 Redesign of the Self-balancing scooter

The self-balancing scooter is a two-wheeled platform, where the wheels are placed in parallel, see Figure 7. The SegWay (SegWay, 2007) is one of the more popular production self-balancing scooters at this moment. Besides the SegWay also non commercial projects are done with self-balancing scooters, e.g. Edgar (Edgar, 2005), Son of Edgar (SonOfEdgar, 2006) and Joe (JOE, 2004).

Figure 7 The ChessWay With this project the idea is similar, but now with cheaper and less parts then the SegWay. Requirements are given for the design of the scooter to introduce more challenge in the project. For example in this project low-cost direct drive BLDC motors are used. In the other projects more expensive motors are used and with gears. Besides the motor, a requirement is given on the use of sensors. In the other projects multiple sensors are used. Mostly used is a combination of a gyroscope and an accelerometer. In this project one of the requirements is to use only one accelerometer for the feedback control. The initial prototype did not give a satisfying result. Now a redesign is done to test if the ViewCorrect Method results in a better working system. With the use of the ViewCorrect method, it also becomes possible to make design decisions on what is minimal needed early in the project. Design space exploration is used to get more insight in the different challenges of the project. The end result of this project needs to be a good working selfbalancing scooter. This chapter describes the test case with using the ViewCorrect design trajectory. This chapter will show the model of the dynamics, the control law design, the embedded control software implementation and the realization and integration of the system.

3.1

Physical system modeling

The first step in the design methodology is the modeling of the dynamics of the system. The physical system modeling step is used in this project to create a simplified model of the setup. This model is used for controller law design, testing controller software with in mind dynamic behavior and design space exploration. Design space exploration is used for choosing the right parts for the setup, choosing the configuration for example the sensors on the setup, etc. The initial essence of the dynamics model was considered the design of the control software for forward motion. For the forward motion the stability is essential. Therefore stability was seen as the initial focus of the model. Due to this point of view the sideward movements were neglected in the model. This resulted in the fact that the model was allowed to be constructed in 2D. In order to make the simulation model, the scooter is modeled using two rigid bodies coupled by a joint. With the use of the rigid body notation, it is possible to construct a model with multiple dimensions. (See also Appendix B). Rigid body 1 (RB1) is the wheel, rigid body 2 (RB2) is the representation of the person and the frame of the scooter, see Figure 9. The joint represent the in-wheel Control Engineering

Model-based redesign of a self-balancing scooter

motor that connects the frame with the wheels. The centre of gravity of rigid body 2 is chosen to be the same as the centre of gravity of the person. Because of the ratio between the mass of the person and the mass of the frame (estimated at 10:1), the mass of the frame is neglected.

Figure 8 Picture of the scooter + person

Figure 9 Model in rigid body notation

The rigid bodies in this project are constructed with the use of bond graphs. (See appendix A) The use of bond graphs offers the possibility to represent multi domains in one model using a unified notation. So these bond graph models can be seen as a core model of the system. Another advantage of the bond graph notation is that it is a graphical notation of the structure of the system, which represents the equations. The model is constructed in 20-sim (CLP, 2002). This gives the possibility to model the dynamics in various representations, e.g. bond graphs, iconic diagrams, etc. With the use of 20-sim verification can be done by simulation. The first simulations are done for the separate rigid bodies to make sure that the separate rigid bodies are modeled correctly. The simulation of the wheel with a given rotation speed showed a movement in the forward direction, as expected. This result was found after determination of the correct initial values. A simulation of the person and frame shows a rotation of the rigid body if a small disturbance form the upright position is given in the model. The integration of the RB1 and RB2 results in the bond graph shown in Figure 10 (More details on the division of the model in rigid bodies can be found in the appendix B). Without a controller the simulation shows a model that represents an uncontrolled scooter. The scooter has a meta stable pose when it stands up right, see Figure 11. If there is a deviation from the upright position, the selfbalancing scooter will fall down as expected (Figure 12).

University of Twente

Control Engineering Figure 10 bond graph of the dynamics of the scooter

Sf
Floor1 C_Wheel_XC

Redesign of the Self-balancing scooter

Engine

MSf2

ControllerOutput
LP-1
filter

GY
friction JWheel

0
ZeroJunction8

MSf

Filter3 JPerson

I 1 TF 0
C_PersonWheel_X R_PersonWheel_X

I 1

ToRotationAngle

TF
Vcom X

0 1

1
FzWheel

1
VhingeWheelX

1
VhingePersonX

I
m Wheelx

Se 0 1 0
C_PersonWheel_Z R_PersonWheel_Z

MTF
Vcom Z

R
R_Wheel_X

Sf
Floor2

1
VhingeWheelZ

1
VhingepersonZ

1
C_Wheel_ZC

I R
R_Wheel_Z

m Wheelz

MTF

RB1

Joint

Acceleration_out

d/dt

Se

RB2

I
m PersX

I
m PersZ

10

Model-based redesign of a self-balancing scooter

Self balancing scooter 0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2 -0.4 0.4 0.2 0 -0.2 -0.4 -0.5 0 0.5 1 time {s} 1.5 2 2.5 Controller output (A)
0.4 0.2 0 -0.2 -0.4 0 -1 -2 -3 -4 100 50 0 -50 -100 2 1 0 -1 -2 0 1 2 3

Self balancing scooter Controller output (A)

Angle person (rad)

Angle person (rad)

Velocity wheel (m/s)

Velocity wheel (m/s)

Velocity person (m/s)

Velocity person (m/s)

4 time {s}

Figure 11 Meta stable pose scooter

Figure 12 unbalanced scooter

When the scooter falls down it is not limited by a ground layer. This ground layer is not implemented in this model because the application is not expected to fall down. With a controller the deviation of the upright position is relatively small and the contact with the floor will not be shown in normal working of the system. So without the controller the stable point for this simulation is when the model is up side down.

3.2

Control law design

The next step is the design of control laws. In this test case the controller is needed to keep the scooter in a stable pose. With the use of the model that resulted from the previous step the controller can be tested whether it delivers the result it should deliver. The required result needs to be determined first. The required result of the controller is called a design criterion. This design criterion is a function which needs to be minimized. With the use of 20-sim the controller can be designed and also verified against the criterion.
Controller System

Figure 13 Controlled system In the test case the criterion for the design of the control laws is chosen to control the angle between the self-balancing scooter and floor to ninety degrees. In other words, the criterion is reducing the deviation from the upright position of the self-balancing scooter to zero. Deviation from the upright positions needs to be minimized. With the criteria the input and output can also be chosen of the model. The criterion of the self-balancing scooter results in an input and an output of the controller. The input of the model is the steering signal to the motors and the output of the model the angle of the scooter. The following step is the design of the controller itself. The first controller in this case is a continuous controller, a continuous controller is chosen as a first experiment to determine if it is possible to control the system at all. A continuous controller is relatively easier constructed, because for example it is not influenced by the sample frequency. With the help of 20-sim it is possible to linearize, around the upright position, such that a transfer function of the physical system is the result With this transfer function, it is possible to generate

University of Twente

Redesign of the Self-balancing scooter

11

different representations of the model. For example a state space notation or a pole and zero notation. With the use of the pole and zero notations the controller in this test case is designed. The first choice in this test case is first to try a relatively simple controller. If a simulation shows that the model can not be controlled with the proposed controller, a more intelligent controller can be designed. With the pole and zero plot it is possible to see the model is instable, due to the poles in the right hand plane. See Figure 14 for the pole and zero plot. With the root locus it is possible to see where the poles and zeros are moving when the model is in closed loop feedback. With the use of the pole and zero plot a PD controller is designed to get a stable controller for the selfbalancing scooter. In the following figures it is shown that the poles on the right hand plane will move to the left. The figures do not show the whole pole-zero plot.
50
0.7

Linear System : Pole Zero Plot

0.6 0.5 0.4 0.3 0.2 0.1

50
0.7

Linear System : Pole Zero Plot

0.6 0.5 0.4 0.3 0.2 0.1

40 30 20 10
0.8

40 30 20 10 Im 0 -10 -20 -30 -40 -50

-40 -30 -20 Re -10 0 10
0.8

0.9

0.9

Im

0 -10 -20 -30 -40 -50

-40

-30

-20 Re

-10

10

Figure 14 pole-zero plot, unstable system

Figure 15 pole-zero plot, stable system

The left figure shows the pole-zero plot of an open system with the pole and zero of the derivative action, the root-locus shows the movement of the poles in the pole-zero plot, with a increasing proportional action. The right figure shows the pole-zero plot of the closed loop system. In this plot the proportional action is chosen which results in that the poles are located in the left hand plane. Simulations are done to verify the working of the controller. At first simulations are done with a deviation of the upright position in the initial conditions. The second simulations are done with the use of a reference profile. This profile simulates the movement of the person on the step, to move forward with the step. The motion profile first accelerates, then having a constant velocity and at the end the self-balancing scooter decelerates. This is also shown in Figure 16. The result of the simulation shows a working controller, after the movements the angle of the person is reduced to zero and the scooter does not fall down. The working of the controller in the real system is not guaranteed by these simulations, because some parts of the model are still in ideal form, for example the sensors, actuators and the controller.

Control Engineering

12 1
20 10 0 -10 -20 0.04 0.02 0 -0.02 -0.04 1 0 -1 -2 -3 0.4 0.3 0.2 0.1 0

Model-based redesign of a self-balancing scooter 2 3

Self balancing scooter Controller output (A)

Angle person (rad)

Velocity wheel (m/s)

Velocity persoon (m/s)

0.3 0.2 0.1 0 -0.1 -1 0 1 2 3 4 time {s} 5 6 7

Reference Profile (m/s)

Figure 16 Simulation results balanced scooter

3.3

Embedded control system implementation

The third step is the implementation of the digital embedded controller. In this step, the model is extended with the properties of the electronics that can have influence on the working of the system. So in this case the model is extended with DA/AD converters, sensor properties, anti aliasing filters and timing constraints. This gives the opportunity to test the entire model including the controller and the relevant hardware properties in the simulation tool. With this third step the model becomes more multidisciplinary. Figure 17 shows the multidisciplinary structure of the model.

Control Engineering

Electrical Engineering
IO_output

Physical system modeling

Reference

Controller

plant

IO_input

Figure 17 Multidisciplinary structure of the model The model of the Self-balancing scooter is grouped in different disciplines. The model is divided with in mind the multidisciplinary structure shown in Figure 17. This can reduce design time, because new developments can be implemented in a relatively easy way. For example another controller only requires replacing the sub model controller. This method of modeling also requires to define the in and University of Twente

Redesign of the Self-balancing scooter outputs of the different blocks. This model is divided in a controller part, IO part and a part for the dynamics of the system.

13

With the introduction of a discrete part in the model, the controller needs to be redesigned to a discrete controller. To redesign the controller we use the Tustin approximation to rewrite the transfer function of the controller, see appendix C for the calculation. With the calculation new parameters for the controller are available. These parameters can be used in the new introduced discrete controller that is available in 20-sim. With these new variables the controller is again verified. In simulation the conversion from continuous to discrete, using the Tustin approximate, showed a negative influence on the behavior of the controller. The working area of the controller is minimized to a very small deviation from the upright position. If the scooter has a 0,1 radian deviation from the upright position the scooter will fall down. With a refinement step of the controller law design the simulation showed a working controller. During the refinement step the controller parameters where changed iteratively till the controller was working. The simulation showed a scooter that can be controlled to the upright position from an initial of 0,1 radian deviation from the upright position and with a reference profile steering the scooter forward and backward. With the use of the model as a virtual machine a good representation can be given of the reaction of the self-balancing scooter.

Figure 18 Animation of the scooter with person The model in the above figure represents, from left to right: 1. 2. 3. 4. 5. A scooter standing still. A scooter accelerating. A scooter moving with a constant velocity forward. A scooter decelerating. A scooter standing still.

In Figure 16 these positions are also represented in the simulation results. During the embedded control system implementation design space exploration is used to evaluate design variants. The following tests are done during this MSc project: Sensor properties Motor Power Sample frequency

With these tests it is possible to evaluate certain influences of design decisions on the self-balancing scooter. For example the used sensor on the self-balancing scooter is tested. The simulation showed that the accuracy of the sensor was sufficient enough for this application. The simulations also showed that the resolution of the A/D converter in the sensor was probably not sufficient enough. With the use of the virtual machine it was also concluded that the position of the sensor had influence on the working of the controller. Simulations showed that the position of the sensor needed to be at the centre of gravity of the person to get the best results. See for more information appendix D. Another example of design space exploration is the determination of the sample frequency that is needed a correct working of the controller. Simulation made it possible to test the system which calculation frequency was needed for a working system. The simulation showed that a higher frequency was advised. At this moment 1000 Hz is used and this results in a good working controller. See also appendix D.

Control Engineering

14

Model-based redesign of a self-balancing scooter

Design space exploration was also used for the motor. The motor is tested whether it can be used in this setup. Because little was known about the motor, the only test for the motor was the power that it needed. During the simulations it showed that the motor needed little power. With this in mind and knowing that the motor needed in simulations only ten percent of its power the conclusion was that the motor can be used in the setup

3.4

Embedded Control Software Realization and Integration

The next step is the realization stage. The first point in the realization is the generation of the code from the model. Before this code is programmed in the real system it is tested in a SIL simulation (Visser et al., 2004). This simulation gives the opportunity to test the real code in a simulation environment, to make sure that the generated code does not contain errors or erroneous behavior. The simulation showed that the code and the model delivered the same signals. Also the code is tested with other accuracies and other data types. 20-sim uses 64 bit doubles as variable type for simulation. The code can also be run on other types of platforms that do not support the use of 64 bit doubles in the code. To guarantee the working of the code also on other platforms tests with other variable types are done. The code is also tested with a fixed point representation and with 32 bit float variables. The fixed point calculation of the model, showed that with too low use of the number of bits the controller does not work anymore. For more information see appendix D. The code runs on a FPGA with a soft-core. The soft-core that is used is the NIOS II soft core from Altera. This soft-core supports floating point calculations, so the generated software from 20-sim (floating point c-code) can run on the FPGA. After the verification of the code the real integration of the system can begin. This is the step where the hardware comes together with the software. At this point the first real testing can begin. With the use of this design trajectory we strive to a first time right. With the verification of each step it is already known that the requirements and criteria of each step are already met. So the real test with this realization step is the correctness of the model, criteria and requirements used in each previous step. The implementation of the control software on the FPGA resulted in a non working setup. During an interdisciplinary meeting, the implementation errors were found. These errors were only found when the complete model of the setup was shown. With this model every step through the systems was mentioned and this resulted in the understanding of the implementation errors without knowing the exact working of the system. But the graphical representation of the model and the specification of the signals introduced insight in the model for each discipline. After the improvements the scooter showed similar behavior with the simulation. If the first results of the implementation are available, the model can also be used to validate the working of the controller on the real hardware. In this test case it was needed to validate the output values of the real controller with the controller in 20-sim. The first measurement showed a deviation of these two signals. With the use of 20-sim it was possible to compare this two signals and do some error detection.

University of Twente

15

4 ViewCorrect evaluated
The ViewCorrect methodology is based on the idea of using an integrated core model in the beginning of the project. The expected benefits of the ViewCorrect methodology are: Design and implementation time is expected to be reduced substantially. Due to efficiency improvements and the possibility within the method to work more concurrently. Higher quality of the resulted system. This is a result of the possibility of the early integration of different design choices in the core model.

The described test case shows the usage of the integrated core models. The structure of the test case is illustrated in Figure 19.

Figure 19 The ViewCorrect test case During the test case the core model is first designed and later on in the project extended with extra information from the different design disciplines. Each design discipline uses the core model to gain more understanding of the complete model. With the introduction of the core model in the beginning of the project resulted in a better understanding of the difficulties during the project. The core model also gives more opportunity for collaborative design. During these meetings the model is used as an overview, which results in the understanding of the system by all disciplines. The use of the core models is a means to communicate between disciplines in a more formal way than social communication (oral and written documentation). Social communication suffers from the misinterpretation of common words that may have different meanings in different disciplines. The core model becomes also the documentation of the project. During project meetings new ideas can be easily made. Due the core models the relevancies can be easily spotted and the result is that only the relevant statements are taken into account. This reduces unnecessary spending design time.

Control Engineering

16

Model-based redesign of a self-balancing scooter

The test case also showed that the software integration was difficult. The introduction of the FPGA, as platform for running the control software, pointed out that it becomes difficult to control and debug the software. During the design phase of the individual parts, testing and verification can be done by using various simulation and design tools. However, the integration of the embedded control software and the FPGA board could not be tested before the real integration. The reason is that testing together in simulation the FPGA core and the embedded control software, using the core model, is not yet possible. The only possibility to find and solve the integration problems was to do an interdisciplinary meeting. During this meeting the core model was used to go step by step through the model. During this interdisciplinary meeting the mismatch between the FPGA embedded control software implementation and the core model was located. Also shown during the test case is that with the core model it is required to make a good interface specification. Using this specification, integration problems can be prevented. The use of the core models also was seen in the coupling of the different disciplines. When for instance the electrical engineer changed a sensor, it had direct influences for the work of the control engineer. Due the use of the core models the control engineer can verify the working of the sensor or discuss with the electrical engineer the requirements for the sensor. In the end the ViewCorrect method showed improvements in the design of an embedded system. With the use of the method it showed that earlier in the project design decisions are made. This results in less need for a prototype. Besides the positive influence on the design decisions, the method also reduces design time with the help of the creating interdisciplinary understanding of the system during the design. Due to these effects the design time is expected to reduce and the quality of the system will improve.

University of Twente

17

5 Conclusions and Recommendations

5.1
5.1.1

Conclusions
Self-balancing scooter

The first tests of the setup with the controller software implemented on the FPGA showed an oscillating scooter. This was also seen in the simulation when no person is on the scooter. It can be concluded that the model of the scooter gives a correct representation. And the controller showed that it works. Testing the scooter with a person is not possible yet because the place for the person is occupied by the FPGA prototyping equipment. It can be concluded that the A/D converter in the sensor is not accurate enough to control the scooter according the criteria. 5.1.2 ViewCorrect

During the test case it showed the advantages of the ViewCorrect methodology. Within a project using the ViewCorrect method the emphasis lies on the co-working of the different disciplines. The need is that the different disciplines work more and more together. This also was seen during the development of the self-balancing scooter. If the designers of the self-balancing scooter were not working as a team, it would be harder to realize the project. This would lead to a longer development time. Due to more team work, it becomes possible for each discipline to use also the knowledge available in the other disciplines. This interaction between the different disciplines can be exploited to gain reduction of the design time. Also needed are correct and clear arrangements between the different disciplines and the possibility to use verification with physical measurable magnitude, in other words team work is of great importance. Due to the modeling of the system a core model is available which helps in making important design decisions that influence on different design disciplines. With the core model and (3D) simulations a prototype is less needed. With the core model and the (3D) simulations a virtual prototype arises. With virtual prototyping the need for realizing real prototypes reduces. Virtual prototyping can also be used for parameter estimation. In this test case the virtual prototype is used for the placement of the sensor, type of sensor and the determination of a correct sample frequency. The modeling and simulations will lead to a common understanding of the system behavior. Reduction of design time is a project goal of the ViewCorrect project. With this test case it is not simple to say that the ViewCorrect will bring reduction of design time for every project. But due to the use of the core model and the possibility of design space exploration in the modeling tools the design becomes more accurate and the quality of the system design is improved.

5.2
5.2.1

Recommendations
Self-balancing scooter

With the use of the model with acceleration as sensor a fair resemblance between model and reality has been found. For completion of the system it is recommended to use a gyroscope instead of the acceleration sensor. With the conclusion that the system can be better made wit a gyroscope other parameters need to be verified. For instance: could the sampling frequency be lower? Is the A/D converter adequate? The current core model is rich enough to perform such tests. The control by the operator has not been investigated and needs attention when the system becomes realized for experiments. 5.2.2 ViewCorrect

For ViewCorrect lessons are learned during the project. This test project showed that the methodology needs to be extended with a process. This is needed to come to full usage of the core models. For example regular interdisciplinary meetings are needed to realize a common understanding between the Control Engineering

18

Model-based redesign of a self-balancing scooter

different disciplines. During these meetings the core models must be used to create interdisciplinary understanding. In the future, additional tooling can be used for more interaction between the different disciplines and their tools. For example it is possible that the used construction drawings tool can calculate the parameters regarding the weight and the inertia of the setup. This then can be reused in the physical modeling of the setup. For the hardware and software integration a co-simulation tool can be designed. This should introduce the possibility of simulating the results of this integration.

University of Twente

Appendix A Bond graphs

19

Appendix A Bond graphs

The bond graphs representation is used to construct the model of the self-balancing scooter. The advantage of bond graphs is that it is domain-independent and it is used in a graphical environment. The fact that it is domain-independent means that the bond graphs can be used in for example electrical or mechanical domain. This can be used in the ViewCorrect idea of core models. The following appendix will give some more information on bond graphs (van den Elshout, 2006). More information can be found in literature (Breedveld and van Amerongen, 1994) The bond graph notation describes dynamical properties of systems using standard elements. These elements are coupled with each other with the use of bonds. The bond connects the ports of the elements and indicates the energy through the system. The elements used in the bond graph notation can be found in Table 1.

Table 1 Bond graph notation The elements in the table are generic elements; each element represents a certain domain specific element. Examples are given in Table 2. C I R Se Sf (M)TF GY Capacitor, spring Mass, Inertia, coil elec. Resistance, friction, damping Voltage source, Force source Current source, Speed source Elec. transformer, gearbox Elec. Engine, Table 2 Bond graph elements

Control Engineering

20 The variables used in the port of the elements are indicted with e, effort, and f, flow. E and f can represent other magnitude. This depends on which domain it has to represent. The product of these two variables represents the power through the bond. The following table shows the different domain dependent variables.

Model-based redesign of a self-balancing scooter

Figure 20 Bond description

Domain electrical mechanical (translation) mechanical (rotation) hydraulical

effort (e) voltage u [V] force F [N] torque T [Nm] pressure p [Pa]

flow (f) current i [A] velocity v [m/s] angular velocity [rad/s] volume flow v [m3/s]

Table 3 Domain specification With this representation it is possible to construct a model of the dynamics of a system. To illustrate the bond graphs method an example is given on making a model with the use of bond graphs. As example we use a RLC network, the network we use is illustrated in the following figure.

Figure 21 Electrical network In this network every element has the same current. So a 1-junction is used to interconnect the different elements. This is showed in the following figure.

Figure 22 Electrical network written with the use of a 1-junction Now the electronic elements can be replaced with the elements of the bond graph notation. The following figure illustrates the bond graph model.

University of Twente

Appendix A Bond graphs

21

Figure 23 Bond graph of the electrical network Without knowledge what domain is used the bond graph model can also represent another model then the electrical model it originates from. For example this bond graph notation can also illustrate the following model.

Figure 24 mechanical model which represents bond graph model

Control Engineering

22

Model-based redesign of a self-balancing scooter

University of Twente

Appendix B Rigid Bodies

23

Appendix B Rigid Bodies

The self-balancing scooter constructed in this project is modeled in 20-sim using a rigid bodies notation. For this project 2D rigid bodies are used. 2D rigid bodies can be used to construct a model that can move in two dimensional spaces. The rigid bodies are constructed with the use of the bond graph notation. The following appendix will describe the rigid body notations. First an introduction on rigid body notation is given, provided by vd elshout. After that the implementation of rigid bodies in this project is given. More on this modeling theory can be found in literature (Bos, 1986).

Rigid body
A rigid body exists of a body fixed coordinate frame, a centre of mass and possible are multiple hinge points. The body fixed frame of the rigid body can be chosen freely. But the best choice to place the frame is in the centre of mass or in one of the hinge points. This will simplify the calculations. The movements of the body are the same as the movements of the frame, so the body moves fixed to the frame. Besides the body fixed frame an inertial frame is used as a reference, this frame will not move. This is shown in the following figure.

Figure 25 rigid body (L) with body fixed frame and inertial frame (S0) Each point on the body can have a certain velocity. There are two different possibilities to describe the velocity, one is with respect to the body fixed frame and the other is with respect to the inertial frame. If for example point P in Figure 25 is fixed on the body the position with respect tot the body fixed frame will not alter. The position with respect to the inertial frame can change. Calculation of the velocity of point P with respect to the inertial frame can be done with the following equation.

The velocity with respect to the inertial frame is the sum of the velocity of the body-fixed frame (base S1) with respect to the inertial frame (base S0), the velocity of the point P with respect to the body fixed frame (S1) and the results of the cross product. This cross product is taken between the rotation of the body-fixed frame S1 with respect to the inertial frame S0, and the position of point P with respect to the body-fixed frame S1. The position is a vector that contains the distances from the point to the body-fixed frame, and the velocity is a vector, containing the velocities in x-, y-, and z-direction. The equation is described with the use of a superscript index. The first S, shows in which coordinate the values are described. The second S indicates with respect to which base the coordinate values are described. For example the equation above describes the velocity of point P with respect to base S0 and in the coordinates of S1. The cross product that is used in the equation is calculated in the following way, see the following equation:

Control Engineering

24

Model-based redesign of a self-balancing scooter

This can also be notated in a matrix vector multiplication. This is shown in the following equation. The results of both the notation are the same.

In this project a 2 dimension notation is used. This result in a more simplified equation, because of a part of the variables are zero. For example if the x,y-plane is used the following equations can be used:

As previously stated the rigid bodies are described with the use of bond graphs. So these equations are translated to a bond graph notation. In the bond graph notation a one-junction represents the velocity of a point and the zero-junction represents the force in a point. The zero- and one-junction resembles the kirchoff laws, the zero-junction sums all the velocitys to zero and the one-junction sums all the forces to zero. In the bond graph notation the MTF stands for a modulated transformer. The modulated part in this MTF is not used in this way, because the MTF is used for the calculation of the cross product. The matrix for the cross product is constant so no modulating input for the matrix is needed. The velocity of the body-fixed frame is indicated by V11, and the velocities of points 1 (origin) and P are indicated by V1 and VP.

Figure 26 Bond graph notation of the rigid body This bond graph notation can now be seen as one rigid body. So a more clear notation for this body can be seen with only the in- and outputs of the body in Figure 27. For a correct working of the rigid body notation in- and outputs are needed in translation and rotation domain.

Figure 27 Submodel of the rigid body

University of Twente

Appendix B Rigid Bodies The model of the self-balancing scooter is made out of more than one rigid body. There are two possible ways to connect to body. First possible connection is a hinge connection and the other possibility is a joint connection. Both can be an actuated or a non-actuated connection. The joint connection is used for a connection between two different bodies and the hinge is used for a connection between a body and a fixed object. The following bond graph notation shows the difference between these two connections.

25

Figure 28 (a) bond graph notation of a joint (b) bond graph notation of a hinge In the figure it is shown that with a joint connection the bodies can rotate independently from each other and with a hinge the translation velocities are constrained to the fixed object. To describe all the velocities of the other bodies with respect to the same inertial frame a coordinate transformation is needed. This transformation translates each point in the body fixed frame to the inertial frame. A rotation matrix is used for this coordinate transformation, see the following equations:

The first matrix translates the coordinates from the body fixed frame to the inertial frame and the second matrix does the opposite. The angle () of the body with respect to the inertial frame is used for the calculation. These matrix multiplications are done in the MTFs that are shown in the eventual notation, see Figure 26.

The self-balancing scooter in rigid body notation

The self-balancing scooter consists of two rigid bodies. The first rigid body is the rigid body of the wheel of the scooter. The other rigid body is the body that represents the person and the frame of the scooter. These two rigid bodies are connected with a joint connection. The wheel is connected to the floor with a hinge. The rigid body of the wheel is constructed in the following way, see Figure 29.

Control Engineering

26
JWheel

Model-based redesign of a self-balancing scooter

I 1 TF Sf 0 1
C_Wheel_XC

ROT_in

1
FzWheel

V_in_X

I
m Wheelx

Se 0 1
V_in_Z

R
R_Wheel_X

Sf

1
C_Wheel_ZC

I
m Wheelz

R
R_Wheel_Z

Figure 29 Bond graph notation of rigid body 1, the arrows points to the Sf sources In this figure it can be seen that in the wheel extra dynamics are placed for damping and friction. Also the hinge connection to the ground is shown here. This can be seen with the use of the Sf sources in the figure connected to the zero-junctions of the translation part. In this rigid body the transformer for the cross product is shown as a TF element. A MTF is not used because the matrix is constant. In this example the hinge point is chosen exactly on the axis so the multiplication for the z axis is zero and so is not displayed in this figure. In the TF used in this figure the multiplication factor is the distance between the hinge point and the centre of mass. In the following figure the rigid body notation of the frame and the person is shown. This rigid body contains the rotational inertia of the frame with the person, the masses of the frame with the person in translation direction, the extra added dynamics (e.g. damping) and also shown in this figure is the coordinate transformation (MTF).

University of Twente

Appendix B Rigid Bodies

JPerson

27

ROT_in

1 TF
Vcom X

ToRotationAngle

V_in_X

Vcom Z

V_in_Z

MTF

Vx 1

Se

I
m PersX

I
m PersZ

Figure 30 Bond graph notation of the person+frame rigid body Besides these two rigid bodies the joint is also constructed in bond graphs. This joint is an actuated joint (motor) and friction is added. This friction represents the friction between the rotation parts in the actuation. In this joint also some extra dynamics is added in the translation directions. These extra dynamics exist of a damper and some friction.

Control Engineering

28

Model-based redesign of a self-balancing scooter

MSf3

Controller_Velocity
friction Engine

MSf
MSf2

GY

0
ZeroJunction8

MSf

LP-1
f ilter

Controller_Angle

Filter3

ROT_in

0
C_PersonWheel_X R_PersonWheel_X

ROT_out

V_in_x

0 0

1
VhingeWheelX

1 MTF
VhingePersonX

V_out_X

V_in_Z

1
VhingeWheelZ

1
VhingepersonZ

V_out_Z

C_PersonWheel_Z R_PersonWheel_Z

Figure 31 Bond graph notation of the joint between the rigid bodies In the end the following representation in rigid bodies notation is formulated for the model of the selfbalancing scooter.

Figure 32 rigid body notation on sub model level

University of Twente

Appendix C Model of the mechatronic self-balancing scooter

29

Appendix C Model of the mechatronic self-balancing scooter

Model self-balancing scooter
During the project a dynamic model of the self-balancing scooter is created. With the use of the rigid bodies made in appendix II the model can be used in 20-sim. Besides the dynamic model of the system also the controller and the behavior of the electronics (I/O) are introduced in the model. The model is divided in the different disciplines: electronic, controller and dynamic model. The resulting model is shown in the following figure.

Control Engineering

Electrical Engineering
IO_output

Physical system modeling

Reference

Controller

plant

IO_input

Figure 33 20-sim mode self-balancing scooter The sub model plant is used for the implementation of the dynamics of the system, within the submodel plant the rigid bodies are used. The submodels IO_input and IO_output are used to incorporate the relevant behavior (sampling, delay, scaling) of the electronics used in the setup. The controller submodel is used to be able to create the controller for this system. The reference in this model is used to generate a profile for the movements of the system. This is to test the working of the system. The implementation of the electronic properties can be seen in the following figure. It shows the input and output in the same figure.
Controller_Output
D A

MotorCurrent

Angle_Discrete

K
ToDecim al

LP-1
f ilter

Acceleration

ToRadians

ToAngle

Filter2

Figure 34 Implementation of the electronics The filter used in the electronics originates from the sensor used. The sensor used in the setup has a built in low pass filter. Also the signal limiter originates from the sensor, the sensor has a maximum/minimum acceleration. After the signal limiter the ToDecimal block was introduced. With this block the acceleration values where calculated to decimal values, this is also done in the sensor. The function of the A/D block is to sample and quantized the signal. After this block a digital signal is available. The sensor also offers the possibility to deliver the angle as output, to come to this solution the acceleration is divided by 9,81. This calculation step was done with the ToAngle block. The last function of the IO is to return the angle value to the controller. This means the factor previously used to come to the decimal value now is used to get the angle value back for the controller.

Control Engineering

30

Model-based redesign of a self-balancing scooter

The output IO is less complicated, the only function used here is the digital to analog conversion. The MotorCurrent is also limited in size. So the D/A converter has limits of -12 and +12. This resembles the limits of the motor current of -12 and +12 ampere. The MotorCurrent signal that is used here is a reproduction of the average current that is send to the motors in the setup with the use of the Pulse Width Modulation. The D/A converter uses 11 bits for the conversion. In the controller sub model, the following implementation is used. The original design of the controller showed a PD controller for the stability control. But simulation showed that with the use of only a PD controller the scooter will not stand still in upright position. So in the design there is chosen to use a controller on the velocity of the scooter. This was only used for simulations purpose, in the real setup only the PD controller on the angle is used. The result of this controller in simulation is that the scooter stays upright and does not accelerate when the scooter is in upright position.
FB_Angle

PD PD

ControlOutput_To_Motor

Reference_Profile

ControlOutput_For_Simulation

FB_velocity

Figure 35 Controllers for the scooter implemented in 20-sim

Discrete vs. Continuous

During the project a continuous controller is designed but in the end the controller will work on a NIOS II soft core in a digital domain. This means that for a better simulation of the setup the controller needs to be in the discrete time domain. To use the continuous time controller in discrete time the transfer function needs to be rewritten (van Amerongen and de Vries, 2001). In this project the Tustin approximation is used to get to a discrete controller function. See the following maple calculations:

With the use of this new transfer function the variables of the discrete controller can be calculated. University of Twente

Appendix C Model of the mechatronic self-balancing scooter The design of the continuous controller resulted in the following parameters for the PD controller. KP = 30 D = 0.25 = 0.1 With the use of the maple results the parameters for the discrete controller can be calculated. This calculation resulted in the following parameters for the discrete controller. KP = 30 D = 0.501 = 0.1 With the use of these parameters the following simulation results where shown.
50 30 10 -10 -30 -50 0.1 Angle person (rad) 0.05 0 -0.05 -0.1 4 2 0 -2 -4 -6 0.3 0.2 0.1 0 -0.1 0.3 0.2 0.1 0 -0.1 -1 0 1 2 3 4 time {s} 5 6 7 8 9 Reference Profile (m/s) Velocity persoon (m/s) Velocity wheel (m/s) Self balancing scooter Controller output (A)

31

Figure 36 Simulation result with discrete controller When this figure is compared with the figure shown in chapter three, it can be seen that the control functions are weakened. With a refinement step new controller parameters are estimated. A discrete controller with the new parameters shows the follow result.

Control Engineering

32
20 10 0 -10 -20 0.1

Model-based redesign of a self-balancing scooter

Self balancing scooter Controller output (A)

Angle person (rad) 0.05 0 -0.05 4 2 0 -2 -4 -6 0.4 0.3 0.2 0.1 0 Reference Profile (m/s) Velocity persoon (m/s) Velocity wheel (m/s)

0.3 0.2 0.1 0 -0.1 -1 0 1 2 3 4 time {s} 5 6 7

Figure 37 Simulation result with discrete controller, after iteration steps

University of Twente

Appendix D Simulation results

33

Appendix D Simulation results

Design space exploration
Working of the sensor For the design space exploration some simulations are done in the following appendix these simulation results are shown. In the design space exploration the chose of the sensor is confirmed with a simulation. With this simulation the sensor is tested if it can be used in this application. To test the sensor, the model is extended with properties of the sensor. This can also be seen in appendix C. In this appendix it is shown that the various properties of the sensor are used in the model, e.g. the accuracy. The resulting simulation shows a working controller, so the sensor can be used in the setup.
1 Self balancing scooter Velocity Person+frame x-axis (m/s)

0.5

-0.5

-1 100 Sensor output

50

-50

-100

10 time {s}

15

20

Figure 38 Simulation results from tests on the sensor properties If the sensor parameters are changed, with less accuracy, the setup can not be controlled. During this test only the sensor parameter is changed, the accuracy of the number of bits is changed.

Control Engineering

34

Model-based redesign of a self-balancing scooter

Self balancing scooter Velocity Person+frame x-axis (m/s)

-5

-10

-15 50 Sensor output

-50

-100

10 time {s}

15

20

Figure 39 Simulation results from tests on the sensor properties, after chancing properties sensor The following simulation shows the results of testing the sensor with the A/D with a maximum input of 20 m/s2 and minimum of -20 m/s2. This result shows that for smaller deviations of the upright position the controller is harder to realize.
5 4 3 2 1 0 -1 -2 -3 -4 -5 0.1 Angle Person (rad) Self balancing scooter Rotation speed wheel (rad/s)

0.05

-0.05

-0.1

-1

4 time {s}

Figure 40 Simulation results sensor test The following test shows the result if a more sensitive sensor is used. The properties are here that a maximum signal of 5 m/s2 and minimum of -5 m/s2 can used as input on the sensor. Both simulations are done with same number of bits.

University of Twente

Appendix D Simulation results

6 5 4 3 2 1 0 -1 -2 -3 -4 0.1 Angle Person (rad) Self balancing scooter Rotation speed wheel (rad/s)

35

0.05

-0.05

-0.1

-1

4 time {s}

Figure 41 Sensor test with a more sensitive sensor These two simulations show the negative influence of the sensor, but because of the small amount of variation it is at this stage not seen as a problem. Besides these simulations also the proposed acceleration sensor is compared with a gyroscope. The sensors are simulated with a person on the step and without a person on the step. During these simulations a low pass filter is used. This 50 Hz low pass filter is chosen because low cost sensors come with a 50 Hz low pas filter.The results of these simulations are shown in the following table. Acceleration sensor Low Pass filter With Person Without Person 50 Hz Working Controller Non working controller Low Pass filter With Person Without Person Gyroscope 50 Hz Working Controller Working Controller

Table 4 Different sensors and controller results These results can be taken into account when the choice of the sensor needs to be reevaluated. The sampling frequency With the introduction of a discrete part in the model, a sample frequency is needed to introduce in the system. With the use of simulation a working sample frequency is chosen. With the use of the model of the self-balancing scooter the sample frequency is tested. Testing a frequency of 100 Hz delivers the following result of the velocity of the setup.

Control Engineering

36

Model-based redesign of a self-balancing scooter

Self balancing scooter Velocity Person+frame x-axis (m/s) 10

-5

Sensor output 400

200

-200

-400 0 5 10 time {s} 15 20

Figure 42 Simulation results with a low sample frequency Testing the setup with a higher frequency (300 Hz) gives the following result, see figure. In this figure can be seen that the setup will get back to the upright position. Only negative is that the signals are very nervous.
Self balancing scooter Velocity Person+frame x-axis (m/s) 2

-1

-2

Sensor output 200

100

-100

-200 0 5 10 time {s} 15 20

Figure 43 Simulation result with sample frequency of 300 Hz The following test uses a frequency of 1000 Hz, this simulation shows a good working controller and the signals are more quietly. Fore the setup a sampling frequency of 1000 Hz is chosen.

University of Twente

Appendix D Simulation results

1 Self balancing scooter Velocity Person+frame x-axis (m/s)

37

0.5

-0.5

-1 100 Sensor output

50

-50

-100

10 time {s}

15

20

Figure 44 Simulation result with sample frequency of 1000 Hz Motor power With the resulting controller and model simulation are done to verify if the motors can be used in the setup. Due to the little knowledge of the motors, only the power can be used for an estimation of the working of the motors. The following plot shows the power that is needed in the Gyrator in the model.
50 40 30 20 10 0 -10 -20 -30 -40 -50 20 10 0 -10 -20 10 Torque (Nm) 5 Rotation speed (rad/s) Slef-balancing scooter P {W}

-5

-10

10 time {s}

15

20

Figure 45 Simulation result of used motor power during motion profile

Control Engineering

38

Model-based redesign of a self-balancing scooter

Sil Simulation
With the generation of the software code, a SIL simulation can be done. With this simulation it is possible to verify if the code is working correct and with accuracies are needed for the variables in the code. In this project the code has been verified with the use of SIL simulation. During this simulation the code has been tested, also for floating points with a 32 bit accuracy and fixed point. The simulation results are shown below. Simulation with fixed point with a lower accuracy then 10 bits before the comma and 10 bits after the comma, the following results are shown.

Figure 46 Simulation result with fixed point calculation, not enough accuracy The step will fall down. With 10 bits, before and after the comma, the controller works. The selfbalancing scooter will move and return to the upright position, see Figure 49.
1 Self balancing scooter Velocity x-axis (m/s)

0.5

-0.5

-1 1 Controller output(double)

0.5

-0.5

-1

10 time {s}

15

20

Figure 47 Simulation result with doubles used in calculation The above figure shows the signals of a working controller with the generated code. The used variables here are doubles.

University of Twente

Appendix D Simulation results

1 Self balancing scooter Velocity x-axis (m/s)

39

0.5

-0.5

-1 1 Controller output(float)

0.5

-0.5

-1

10 time {s}

15

20

Figure 48 Simulation result with floats used in calculation With this simulation it can be seen that the use of floats (32 bit) variables does not change the working of the controller.
1 Self balancing scooter Velocity x-axis (m/s)

0.5

-0.5

-1 1 Controller output(fixed point)

0.5

-0.5

-1

10 time {s}

15

20

Figure 49 Simulation result with fixed point calculation, enough accuracy This simulation shows the results of simulation with variable type fixed point, with 10 bits before and after the comma. This also shows a working controller.

Control Engineering

40

Model-based redesign of a self-balancing scooter

University of Twente

Literature

41

Literature
van Amerongen, J. and T.J.A. de Vries (2001), Digitale regeltechniek. Bos, A.M. (1986), Modelling Multibody Systems in Terms of Multibond Graphs with Application to a Motorcycle, PhD-Thesis, Control Engineering, University of Twente, Enschede, pp. 226, ISBN: 90-90001442-X. Breedveld, P.C. and J. van Amerongen (1994), Dynamische Systemen: modelvorming en simulatie met bondgrafen, Open Universiteit, Enschede, ISBN: 90 358 1302 2. Broenink, J.F. (2005), Title: ViewCorrect Predictable Co-Design for distributed embedded mechatronic control systems, http://www.ce.utwente.nl/ViewCorrect/ProgressTES7020w.pdf. Broenink, J.F. and G.H. Hilderink (2001), A structured approach to embedded control systems implementation, in: 2001 IEEE International Conference on Control Applications, M. W. Spong, D. Repperger and J. M. I. Zannatha (Eds.), IEEE, Mxico City, Mxico, pp. 761-766, ISBN: 0-7803-6735-9. CE (2007), website Control engineering group at UT, http://www.ce.utwente.nl/. Chess (2007), website Chess, http://www.chess.nl/. CLP (2002), 20-SIM, http://www.20sim.com. Corporaal, H. (2006), Embedded System Design, in: Progress White Papers 2006, F. Karelse (Ed.) STW, Utrecht, pp. 7-27, ISBN: 978-90-73461-00-0. Edgar (2005), Website for the Edgar project, http://www.mecheng.adelaide.edu.au/robotics/robotics_projects.php?wpage_id=44&title=18& browsebyauthor=115. van den Elshout, G.P. (2006), Obtaining time reduction, http://www.ce.utwente.nl/rtweb/publications/Msc2006/pdf-files/007CE2006_vdElshout.pdf. ICS/ES-EE (2007), Electronic System group at the TU Eindhoven, http://www.es.ele.tue.nl/. JOE (2004), Website for the JOE project, http://leiwww.epfl.ch/joe/. Oc (2007), Oc website, http://www.oce.com/. PROGRESS (2007), PROGRESS website, http://www.stw.nl/programmas/progress/. SegWay (2007), Website SegWay, http://www.segway.com/. SonOfEdgar (2006), Website for the Son of Edgar project, http://www.mecheng.adelaide.edu.au/robotics/robotics_projects.php?wpage_id=44&title=31& browsebytitle=1. Visser, P.M., M.A. Groothuis and J.F. Broenink (2004), Multi-Disciplinary Design Support using Hardware-in-the-Loop Simulation, in: 5th PROGRESS Symposium on Embedded Systems, F. Karelse (Ed.) Nieuwegein, NL, pp. 206-213, ISBN: 90-73461-41-3.

Control Engineering