Wheeled Inverted Pendulum with Embedded Component ... - CiteSeerX

Wheeled Inverted Pendulum with Embedded Component System: a Case Study Takuya Azumi, Hiroaki Takada Graduate School of Information Science Nagoya University Nagoya, Japan {takuya,hiro}@ertl.jp

Takayuki Ukai Witz Corporation Nagoya, Japan [email protected]

Abstract—Software component techniques have been widely used for enhancement and the cost reduction of software development. We herein introduce a component system with a real-time operating system (RTOS). A case study of a twowheeled inverted pendulum balancing robot with the component system is presented. The component system can deal with RTOS resources, such as tasks and semaphores, as components. Moreover, a trace functionality which is a new functionality to confirm the state of components or calling components without modification of C source code is introduced. Keywords-component-based development; real-time operating system;

I. I NTRODUCTION Recently, software component technologies for embedded systems have received increasing attentions from researchers [1]. For example, component technologies for embedded systems, such as Koala component [2], SaveCCT [3], and THINK framework [4] have been developed. TOPPERS Embedded Component System (TECS) [5] has been investigated in the last several years. It is possible to estimate the memory consumption of an entire application because TECS adapts a static configuration. The static configuration means that both the configuration of component behaviors and interconnections between components are static. Furthermore, TECS supports optimization of the interface code generated by an interface generator [6]. Therefore, it is easy to reuse components because component granularity is small compared with existing component systems. TECS also deals with RTOS resources, such as tasks and semaphores, as components. In this paper, through a case study of a two-wheeled inverted pendulum balancing robot, the way to effectively use RTOS resources on our component system and a trace functionality which is a new functionality to confirm the state of components or calling components without modification of C source code are introduced. There are the following three benefits of using RTOS resources as components. It is easy to configure the kernel of RTOSes because a new statement of component description that is used to generate kernel configuration file of RTOSes is proposed. It is easy to understand the software structure because RTOS resources can be represented on a component diagram. It is easy to

嵦嵨嵯嵯嵷嵼嵳嵨崼嵷嵖嵤嵶嵮

Hiroshi Oyama OKUMA Corporation Niwa-gun, Japan [email protected]

嵦嵤嵯嵯崢嵳嵲嵵嵷 嵦嵄嵲嵧嵼

嵨嵱嵷嵵嵼崢嵳嵲嵵嵷 嵨嵄嵲嵧嵼 嵦嵨嵯嵯嵷嵼嵳嵨崼嵷嵄

嵦嵨嵯嵯

嵦嵨嵯嵯

嵖嵤嵶嵮嵃

嵶嵬嵪嵱嵤嵷嵸嵵嵨崼嵶嵖嵤嵶嵮嵄嵲嵧嵼

Figure 1.

崢嵄

Component Diagram.

reuse components because components are independent of an RTOS. This paper is organized as follows. Section II depicts the overview of TECS, and the way of RTOS resources as components in TECS. Section III represents the case study of a two-wheeled inverted pendulum balancing robot with TECS. Relate Works are described in Section IV. Summaries of the present research is considered in Section V. II. RTOS R ESOURCE AS C OMPONENTS This section describes the overview of TECS and the way to effectively use RTOS resources in TECS. A. TECS A cell is an instance of a component in TECS. Cells are properly connected in order to develop an appropriate application. A cell has entry port and call port interfaces. The entry port is an interface to provide services (functions) to other cells. The service of the entry port is called the entry function. The entry port and the call port have signatures (sets of services). A signature is the definition of interfaces in a cell. A cell type is the definition of a cell, such as the Class of an object-oriented language. A cell is an entity of a cell type. Figure 1 shows an example of a component diagram. Each rectangle represents a cell. The dual rectangle depicts a active cell that is the entry point of a program such as a task and an interrupt handler. The left cell is a TaskA cell, and the right cell is a B cell. Here, each of tTask and tB represents the cell type name. The triangle in the B cell depicts an entry port. The connection of the entry port in the cells describes a call port.

1 [active] 2 celltype tTask { 3 [inline] entry sTask eTask; 4 [inline] entry siTask eiTask; 5 call sTaskBody cBody; 6 attr{ 7 ID id = C_EXP("TSKID_$id$"); 8 [omit] ATR attribute = C_EXP("TA_NULL"); 9 [omit] PRI priority; 10 [omit] SIZE stackSize; 11 }; 12 factory { 13 write("tecsgen.cfg", 14 "CRE_TSK(%s,{%s,&$cb$ ,tTask_start_task,%s,%s,NULL });", 15 id,attribute,priority,stackSize); 16 }; 17 };

啗唲啈啕啌啒啇啌商唶啄啖啎 嵨嵅嵼嵦嵯嵬嵦

啗唥啜商問啌商 唪啄啑啇問啈啕

Figure 4.

1 2 3 4 5 6 7

嵦嵄嵲嵧嵼

嵨嵬嵖嵤嵶嵮

Component Diagram of Periodic Task.

signature siHandlerBody { void main(void); }; signature sCyclic{ ER start(void); ER stop(void); }; Signature Description of tCyclicHandler.

Cell Type Description

1 CRE_TSK(TASKID_tTask_TaskA,{TA_ACT, &tTask_CB_tab[0],tTask_start_task, 1,1024,NULL}); Figure 3.

啗唶啄啖啎

嵨嵖嵤嵶嵮

Figure 5. Figure 2.

啗唶啄啖啎 唣商啗啌啙啄啗啒啕

Generated Static API from Factory Statement.

The description of a component in TECS can be divided into three descriptions: a signature description, a cell type description, and a build description. Each description is explained in [5] in detail. An interface generator generates interface code (.h or .c) of the C language and system configuration files (.cfg) for an RTOS from the signature, cell type, and build descriptions. B. Factory Statement A factory statement is used to automatically generate a static API for a kernel configuration when cells are instantiated. Figure 2 describes an example of cell type description to define components for the task of an RTOS. Figure 3 represents the static API from the factory statement (Lines 12-16 in Figure 2). The static API creates a task with an ID number specified by a task id, such as TASKID tTask TaskA, based on the information contained in a parameter of the static API. TA ACT, &tTask CB tab[0], tTask start task, 1, 1024, and NULL represent the attribute of the task, the extend information passed as a parameter, the start address of the task, the initial value of the task priority, the stack size, and the base address of the task’s stack space, respectively. If the stack size is NULL, the kernel allocates a memory area. C. Composite Cell Type TECS provides several levels of composition for application developers. A composite cell type includes two or more cells. Figure 4 is one of the examples of a composite cell

1 [active] 2 celltype tCyclicHandler { 3 [inline] entry sCyclic eCyclic; 4 call siHandlerBody ciBody; 5 attr { 6 ID id = C_EXP("CYCHDLRID_$id$"); 7 [omit] ATR attribute = C_EXP("TA_NULL"); 8 [omit] RELTIM cyclicTime; 9 [omit] RELTIM cyclicPhase = 0; 10 }; 11 factory{ 12 write( "tecsgen.cfg", 13 "CRE_CYC( %s,{%s,$cbp$, tCyclicHandler_start,%s,%s});", id,attribute,cyclicTime,cyclicPhase); 14 }; 15 }; Figure 6.

Cell Type Description of tCyclicHandler.

type. In this case, a periodic task cell type includes three cells; a cyclic handler cell, a cyclic handler body cell, and a task cell. The cyclic handler cell type (tCyclicHandler) is a time event handler periodically activated to invoke the cyclic handler body. Figure 5 represents the signature description of tCyclicHandler. The siHandlerBody signature is to invoke the cyclic handler body. The sCylic signature is to manage the cyclic handler cell. Figure 6 represents the cell type description of tCyclicHandler. The tCyclicHandler cell type has two interfaces (Lines 3-4). The factory statement (Lines 11-14) for tCyclicHandler is defined to generate the static API of the cyclic handler. The cyclic handler body cell type (tTaskActivator) is to activate the task cell. Figure 7 represents the cell type description of tTaskActivator. The tTaskActivator has two interfaces. One is entry port (eiBody) which is invoked

1 celltype tTaskActivator{ 2 entry siHandlerBody eiBody; 3 call siTask ciTask; 4 }; Figure 7.

Cell Type Description of tTaskActivator.

1 void eiBody_main(CELLIDX idx){ 2 CELLCB *p_cellcb; 3 if (VALID_IDX(idx)) { 4 p_cellcb = GET_CELLCB(idx); 5 } 6 ciTask_activate(); 7 } Figure 8.

C Source Code of tTaskActivator.

1 [active] 2 composite tPeriodicTask { 3 entry sCyclic eCyclic; 4 entry sTask eTask; 5 entry siTask eiTask 6 call sTaskBody cBody; 7 attr { 8 ATR cyclicAttribute = C_EXP("TA_NULL"); 9 RELTIM cyclicTime; 10 RELTIM cyclicPhase = 0; 11 PRI priority; 12 SIZE stackSize; 13 }; 14 cell tTask Task{ 15 attribute = C_EXP("TA_NULL"); 16 priority = composite.priority; 17 stackSize = composite.stackSize; 18 cBody => composite.cBody; 19 }; 20 cell tTaskActivator CyclicMain{ 21 ciTask = Task.eiTask; 22 }; 23 cell tCyclicHandler CyclicHandler{ 24 ciBody = CyclicMain.eiBody; 25 attribute = composite.cyclicAttribute; 26 cyclicTime = composite.cyclicTime; 27 cyclicPhase = composite.cyclicPhase; 28 }; 29 composite.eTask => Task.eTask; 30 composite.eiTask => Task.eiTask; 31 composite.eCyclic => CyclicHandler.eCyclic; 32 }; Figure 9.

Cell Type Description of tPeriodicTask.

by the cyclic handler and the other is call port (ciTask) which is to activate a task. Figure 8 shows entry function of tTaskActivator. A call port function (Line 6) is used to invoke the function of connected cell. The call port function is generated by the interface generator. Figure 9 shows the cell type description of a composite cell type. As mentioned above, the tPeriodicTask includes

1 cell tPeriodicTask PeriodicTask{ 2 cBody = B.eBody; 3 cyclicTime = 10; 4 priority = 5; 5 stackSize = 512; 6 }; Figure 10.

Build Description of PeriodicTask.

three cells: Task cell (Lines 14-19), CyclicMain cell (Lines 20-22), and CyclicHandler cell (Lines 23-28). The attributes of composite cell type can be specified in the similar way with shown in Lines 7-13. These attributes need to delegate to the attribute of inner cells (Lines 16-17, and 25-27). As well, call port (Line 18) and entry port (Lines 29-31) need to delegate to the interfaces of inner cells. As shown in Figure 10, the way to instantiate a composite cell type is the same as the normal cell type. Therefore, application developers can describe the build description without regard to the composite cell type. The benefits associated with using a composite cell type are significant reductions in the complexity of component connection because several cells can be treated as a single cell type, which enhances usability through the connection of cells for an application developer (component user). Several component models, such as Koala component and SaveComp component model, also support a component composition mechanism for naming a collection of components and hiding its internal structure. It is, however, more effective to use the composite cell type with factory statements in TECS. For example, a serial port component, one of the composite cell type, includes two factory statements to create semaphores. These semaphores are to manage a send buffer and a receive buffer, respectively. Two static APIs are automatically generated when application developers use the serial port component. III. T WO -W HEELED I NVERTED P ENDULUM BALANCING ROBOT A. Component Diagram of the Robot Figure 11 shows pictures of a two-wheeled inverted pendulum balancing robot, and Figure 12 represents its component diagram. The robot has three types of sensor: a gyroscope, a rotary encoder, and a current sensor. A gyroscope cell measures an orientation based on the principles of the angular momentum. A rotary encoder cell converts the angular position of an axle to an analog code. A motor current sensor cell detects the electrical current. A/D converter cell converts continuous signals to discrete digital numbers. A motor cell controls a motor. A motor manager cell is activated by a timer to manage the motor. A user control cell performs forward movement, back movement, right turn, left turn, and user commands, from the dataqueue. A ZigBee receiver cell sends the received user command to

唵啈啑啖啒啕唂唲啄啕啗

⋇ 唷啖啈啕唂唥啒啑啗啕啒問唂唲啄啕啗唂

唲啈啕啌啒啇啌商唂 唶啄啖啎 唓唒啐啖

唶啄啖啎

⋉

唣唦 唥啒啑啙啈啕啗啈啕

唩啜啕啒啖商啒啓啈 ⋈

唷啖啈啕 唥啒啑啗啕啒問

㪚㪸㫃㪺

⋊ 唴啌啊啋啗 唴啒啗啄啕啜唂 唧啑商啒啇啈啕

唶啕啄商啈

唫唵唴

⋈

⋇ 唼啌啊唤啈啈 唴啈商啈啌啙啈啕

唶啄啖啎

唦啄啗啄 唳啘啈啘啈

‫ڹںہ‬

唧唰唥唒唕

⋊ 售啈啉啗 唴啒啗啄啕啜唂 唧啑商啒啇啈啕

唫唵唴

唯啒啗啈啕 唯啄啑啄啊啈啕

唶啌啐啈啕 唔唒唒型ۢ

唯啒啗啒啕唂唲啄啕啗 唲啈啕啌啒啇啌商唂唶啄啖啎 ⋋

⋌ 售啈啉啗 唥啘啕啕啈啑啗唂 唵啈啑啖啒啕

唣商啗啌啙啄啗啈 唶啄啖啎

Figure 12.

唴啌啊啋啗 唥啘啕啕啈啑啗唂 唵啈啑啖啒啕

售啈啉啗唂唯啒啗啒啕

⋉ 唥啜商問啌商 唪啄啑啇問啈啕

唴啌啊啋啗唂唯啒啗啒啕

⋉

唣唦 唥啒啑啙啈啕啗啈啕

唶啄啖啎

⋌

⋋

唣唦 唥啒啑啙啈啕啗啈啕

Component Diagram of Wheeled Inverted Pendulum.

㪎㪇㪇

嵜嵬嵪嵄嵨嵨

㪍㪇㪇

嵏嵲嵧嵸嵯嵨

㪌㪇㪇

嵏嵲嵷嵨嵵

嵆嵬嵶嵮

EQWPVU

㪋㪇㪇

嵔嵲嵷嵤嵵嵼

㪊㪇㪇 㪉㪇㪇 㪈㪇㪇

嵉嵼嵵嵲嵕嵦嵲嵳嵨

㪇 㪄㪈㪇㪇

㪇

㪉

㪋

㪍

㪏

㪈㪇

㪄㪉㪇㪇

㫋㫀㫄㪼㩿㫊㪼㪺㪀 Figure 11.

Pictures of Wheeled Inverted Pendulum. Figure 13.

the dataqueue. A calc cell is activated by a periodic task to calculate the value for a proportional-integral controller which is a generic control loop feedback mechanism. As mentioned above, a periodic task cell composes three cells: a cyclic handler cell, a cell to activate a task, and a task cell as shown in the lower left of Figure 12. The same number on the top left of rectangles in Figure 12 represents the same cell type. It is easy to reuse components because the component granularity of TECS is small compared with those of existing component systems. B. RTOS Resources When RTOS resource cells, tasks, a periodic task, a dataqueue, and ISR (Interrupt Service Routine) cells are instantiated, the kernel configuration file including the static API is automatically generated. Filled the rectangles in

Results of Prove for Right Rotary Encoder.

Figure 12 show RTOS resource cells. It is possible to change the configuration files depended on RTOSes, such as µITRON [7] and OSEK [8], by using the factory statement. Therefore, RTOS resource cells are independent of RTOSes. C. Trace Functionality A trace functionality supports that the developer can confirm the state of cells or calling cells without modification of C source code. Figure 13 depicts results of software prove for the value of the right rotary encoder. To realize the trace functionality, a through keyword is used for inserting a cell between cells. The way of using through keyword is explained in [9]. Figure 14 is an example of using the through keyword. The upper part of Figure 14 represents the component models, while the lower part

cell tB B{ }; cell tA A{ cCall = B.eEntry; }; Figure 14.

cell tB B{ }; cell tA A { [through(TracePlugin)] cCall = B.eEntry; };

An Example of through Description.

shows each build description. The through keyword is described only before the description (cCallPort=B.eEntryPort) of the connection.“TracePlugin” represents the type of plugin. The plug-in is used to define the inserted cells and to generate C-language source code when interface code is generated by the interface generator. The application developers need to select the plug-in provided by component developers for inserting the cell. In this case, the plug-in of TracePlugin is used to obtain the value of the right rotary encoder. IV. R ELATE W ORKS Koala component model [2] is intended for consumer electronics such as televisions. RTOS resources as componentsc, however, are not supported. SaveComp Component Technology (SaveCCT) [3] is intended for embedded control applications in vehicular systems. SaveCCT supports resource-efficiency, predictability and safety in the vehicular domain. It is, however, easy to adapt other domain because this technology specializes vehicular system. SaveCCT provides a task allocation functionality. Other RTOS resources, however, are not supported. nesC [10] is to support component-oriented application design. nesC has been used to implement TinyOS [11], a small operating system for sensor networks. The system is generally smaller and provides less functionalities than RTOSes. THINK framework [4] is an implementation of FRACTAL component model [12]. THINK can also deal with RTOS resouces for µC/OS-II as components. THINK, however, does not support the trace functionality to confirm the state of components or calling components without modification of C source code. V. C ONCLUSIONS This paper has described the application of TECS to a two-wheeled inverted pendulum balancing robot. We have proposed the factory statement that is used to generate a kernel configuration file of an RTOS. There are three benefits of using RTOS resources as component: configurability the kernel of the RTOS, understandability the software structure, reusability components.

Moreover, the trace functionality has been introduced to confirm the state of cells or calling cells without modification of C source code. Moreover, the case study has shown understandable software structure. R EFERENCES [1] I.-L. Yen, J. Goluguri, F. Bastani, and L. Khan, “A component-based approach for embedded software development,” in Proc. Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing,, May 2002, pp. 402–410. [2] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee, “The Koala component model for consumer electronics software,” IEEE Computer, vol. 33, no. 3, pp. 78–85, Mar. 2000. ˚ [3] M. Akerholm, J. Carlson, J. Fredriksson, H. Hansson, J. H˚akansson, A. M¨oller, P. Pettersson, and M. Tivoli, “The SAVE approach to component-based development of vehicular systems,” Journal of Systems and Software, vol. 80, no. 5, pp. 655–667, May 2007. [4] F. Loiret, J. Navas, J.-P. Babau, and O. Lobry, “Componentbased real-time operating system for embedded applications,” in Proc. 12th InternationalSymposium on Component-Based Software Engineering, 2009, pp. 209–226. [5] T. Azumi, M. Yamamoto, Y. Kominami, N. Takagi, H. Oyama, and H. Takada, “A new specification of software components for embedded systems,” in Proc. 10th IEEE International Symposium on Object/component/service-Oriented Real-Time Distributed Computing, May 2007, pp. 46–50. [6] T. Azumi, H. Oyama, and H. Takada, “Optimization of component connections for an embedded component system,” in Proc. IEEE/IFIP 7th International Conference on Embedded and Uniquitous Computing, Aug. 2009, pp. 182–188. [7] H. Takada and K. Sakamura, “µITRON for small-scale embedded systems,” IEEE Micro, vol. 15, no. 6, pp. 46–54, Dec. 1995. [8] OSEK/VDX, Operating System, Version 2.3.3, 2005. [9] T. Azumi, H. Oyama, and H. Takada, “Memory allocator for efficient task communications by using rpc channels in an embedded component system,” in Proc. the 12th IASTED International Conference on Software Engineering and Applications, Nov. 2008, pp. 204–209. [10] D. Gay, P. Levis, R. von Behren, M. Wels, E. Brewer, and D. Culler, “The nesc language: A holistic approach to networked embedded systems,” in Proc. the ACM SIGPLAN 2003 Conference on Programming language design and implementation, Jun. 2003, pp. 1–11. [11] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, “System architecture directions for networked sensors,” ACM SIGPLAN Notices, vol. 35, no. 11, pp. 93–104, 2000. [12] E. Bruneton, T. Coupaye, M. Leclercq, V. Qu´ema, and J.B. Stefani, “The fractal component model and its support in java,” Software - Practice and Experience (SPE), vol. 36, no. 11-12, pp. 1257–1284, 2006.