Chapter 5 Implementation
5.2 ESAIR Compact Version Implementation
The bipedal robot is named PAPA-MAN (shown in Figure 5-2). Figure 5-3 shows its hardware architecture. The PAPA-MAN architecture can be divided into three parts: central control board, actuator control board and sensor control board. PIC18F452 is used as the central controller in those three boards. The actuator control board processes an operation received from the central control board and sends instructions to all servo motors on the robot system. The sensor control board receives data from pressure sensors and sends those data to
the central control board. The central control board has two functions: receiving information from the sensor control board and the remote control center and sending operational data to the actuator control board.
\
Figure 5-2: PAPA-MAN
Figure 5-3: Hardware architecture of PAPA-MAN
The software architecture of PAPA-MAN adopts ESAIR MIN, which is built in to its mechanism. The Human-Machine Interface is inside the remote center.
PAPA-MAN has several functions including auto-balancing, standing up, sitting down, prostrating and dancing. Auto-balancing is a reaction built in to PAPA-MAN. When its balance is disturbed, the abnormality will be detected by pressure sensors and sent to the central control board. The other four operations are performed by instructions sent from the remote control center. Those operations may be initialized by the behaviors or by the developer with the Human-Machine Interface.
Figure 5-4: Software Implementation of PAPA-MAN
As PAPA-MAN has no remote control center, ESAIR MIN has been implemented. Auto- balancing and the received operations from the remote control center are categorized as reaction classes. The reaction classes exist in the MCU of the central control board. The sensor class and the actuator class communicate with the central control board. The sensor class is built into the MCU of the sensor control board and the actuator class is built into the MCU of the actuator control board. Figure 5-4 shows the implementation of ESAIR MIN in PAPA-MAN. As compared with Figure 3-5, the three classes of ESAIR MIN are built into the software of PAPA-MAN. Nevertheless, because of the usage limitation of the MCU, the
software realization of those classes is implemented by the basic functions’ API. The reaction class comprises its four main functions: receiving information from the sensor class, receiving information from the remote control center, sending operation instructions to the actuator class and making decisions based on existing reactions. The actuator class and sensor class include two main functions: managing the hardware resource and communicating with the central control board.
Figure 5-5: PAPA-MAN software architecture without ESAIR MIN
Without ESAIR, the software architecture of PAPA-MAN embodies a normal sequential programming architecture, shown in Figure 5-5. The program is based on a main loop that passes on received commands from the remote center to operate sub-operations. The sub-operations are the pre-defined PAPA-MAN operations such as standing up and sitting down. Those operations decode the outside commands and send a specific sequence of actuator controls, which are stored in the memory, to the actuators’ control boards.
Using ESAIR MIN in PAPA-MAN redesigns the software architecture to achieve a new
modularity, ease of maintenance, and ease in adding new operations. The PAPA-MAN software architecture with ESAIR MIN is shown Figure 5-6. Figure 5-6 illustrates the Reaction class in PAPA-MAN’s central control board, and the code block A, B, C in Figure 5-6 is identical to the blocks in Figure 5-5. Using an object-oriented approach to redesign the program can increase the flexibility, and make it easier to maintain and add new sub-operations.
Figure 5-6: PAPA-MAN software architecture with ESAIR MIN
Chapter 6 Conclusion
In this thesis, we proposed embedded software architecture for intelligent robots (ESAIR) and implemented it on the mobile robot systems STARFISH and PAPA-MAN. With ESAIR, the devices and the corresponding software modules can be easily inserted and removed from the robot system without redesigning the architecture.
In addition, two different versions of ESAIR have been created, ESAIR STD and ESAIR MIN, to accommodate various robot system platforms. ESAIR marks the beginning of research toward the goal of a general and uniform architecture that suits various hardware platforms and accommodates all sensors and actuators. The experimental results show that with this architecture in place, developers can concentrate on implementing robotic behaviors instead of working out the control codes used to drive physical devices. It is obvious that the ESAIR is useful in developing highly robust embedded robot systems.
Our work will continue as we attempt to coordinate multiple robots performing complex behaviors. Under our chosen open-source licensing model, the proposed ESAIR software architecture is open to the public, along with all its companion device drivers and user-land applications.
References
[1] M. Montemerlo, N. Roy and S. Thrun, "Perspectives on standardization in mobile robot programming: the Carnegie Mellon Navigation (CARMEN) Toolkit," in Proceedings IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 3, pp.
2436-2441 vol.3, 2003.
[2] B. P. Gerkey, R. T. Vaughan, K. Stoy, A. Howard, G. S. Sukhatme and M. J. Mataric,
"Most valuable player: a robot device server for distributed control," in IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 3, pp. 1226-1231 vol.3, 2001.
[3] R. T. Vaughan, B. P. Gerkey and A. Howard, "On device abstractions for portable, reusable robot code," in IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 3, pp. 2421-2427 vol.3, 2003.
[4] B. P. Gerkey, R. T. Vaughan, A. Howard, "The Player/Stage Project: Tools for multi-robot and distributed sensor systems," in Proceedings of the International Conference on Advanced Robotics (ICAR03), pp. 317-323, 2003.
[5] T. H. J. Collett, B. A. MacDonald, B. P. Gerkey, "Player 2.0: Toward a practical robot programming framework," in Proceedings of the Australasian Conference on Robotics and Automation (ACRA 2005), Sydney, Australia, December 2005.
[6] Player Robot Server ver 0.7.4a User Manual, 2000.
[7] R. Volpe, I. Nesnas, T. Estlin, D. Mutz, R. Petras and H. Das, "The CLARAty architecture for robotic autonomy," IEEE Proceedings of Aerospace Conference, vol. 1, pp.
1/121-1/132 vol.1, 2001.
[8] I. A. D. Nesnas, A. Wright, M. Bajracharya, R. Simmons and T. Estlin, "CLARAty and challenges of developing interoperable robotic software," in Proceedings IEEE/RSJ
International Conference on Intelligent Robots and Systems, vol. 3, pp. 2428-2435 vol.3, 2003.
[9] I. A. D. Nesnas, R. Simmons, D. Gaines, C. Kunz, A. Diaz-Calderon, T. Estlin, R.
Madison, J. Guineau, M. McHenry, I. H. Shu, D. Apfelbaum, "CLARAty: Challenges and steps toward reusable robotic software," International Journal of Advanced Robotics Systems, Vol. 3, pp 023-030, 2006.
[10] C. Cote, D. Letourneau, F. Michaud, J. -. Valin, Y. Brosseau, C. Raievsky, M. Lemay and V. Tran, "Code reusability tools for programming mobile robots," in Proceedings IEEE/RSJ International Conference on Intelligent Robots and Systems, vol. 2, pp.
1820-1825 vol.2, 2004.
[11] C. Cote, Y. Brosseau, D. Letourneau, C. Raievsky, F. Michaud, "Robotic software using MARIE," International Journal of Advanced Robotics Systems, Vol. 3, pp 055-060, 2006..
[12] H. Utz, S. Sablatnog, S. Enderle and G. Kraetzschmar, "Miro - middleware for mobile robot applications," Robotics and Automation, IEEE Transactions on, vol. 18, pp. 493-497, 2002.
[13] H. Bruyninckx, "Open robot control software: the OROCOS project," in Proceedings IEEE International Conference on Robotics and Automation, vol. 3, pp. 2523-2528 vol.3, 2001.
[14] A. Orebäck, H. I. Christensen, "Evaluation of Architectures for Mobile Robotics,"
Autonomous Robots, vol. 14, pp. 33, 2003.
[15] H. Bruyninckx, P. Soetens and B. Koninckx, "The real-time motion control core of the Orocos project," in Proceedings IEEE International Conference on Robotics and Automation, vol. 2, pp. 2766-2771 vol.2, 2003.
[16] Orocos project http://www.orocos.org/
[17] C. Schlegel. "A component approach for robotics software: communication patterns in the OROCOS context," In 18. Fachtagung Autonome Mobile Systeme (AMS), Informatik aktuell, pages 253-263. Springer, Karlsruhe, December 2003.
[18] A. Brooks, T. Kaupp, A. Makarenko, S. Williams and A. Oreback, "Towards component-based robotics," in IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 163-168, 2005.
[19] A. Makarenko, A. Brooks, T. Kaupp. "Orca: Components for Robotics, "IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2006). Workshop on Robotic Standardization.
[20] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku and W.K. Yoon, "RT-middleware:
distributed component middleware for RT (robot technology)," in IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 3933-3938, 2005.
[21] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku and W.K. Yoon, "RT-Component Object Model in RT-Middleware—Distributed Component Middleware for RT (Robot Technology)," in IEEE International Symposium on Computational Intelligence in Robotics and Automation, pp. 457-462, 2005.
[22] R. R. Murphy, Introduction to AI Robotics. MIT Press, 2000.
Appendix A
Software Realization of Reaction Class on PAPA-MAN
In this thesis, the Reaction class is implemented on PAPA-MAN using the ESAIR compact version. It is divided into two parts: a platform-independent part and platform-dependent part. The platform-independent part includes a specific operation code and the platform-dependent handles communication and reading/writing methods. Some reactions handled are: receiving information from the sensor class, receiving information from the remote control center, sending operations to the actuator class, and making decisions based on previous reactions.
A.1 Properties
Table 2 shows the main properties of the Reaction class in PAPA-MAN. Those properties are public and are used in Reaction class methods.
Table 2. Properties of the Reaction class Name Description
CommandFromPC The command receives from PC by wireless RS-232 I2CMemAddr Address to external memory
I2CMemData Data to external memory InfoReceiveFromSensor Data from sensor
CommandSendToActuator Command to actuator
PCCommandDecodeTable Look up the PC command for operation ControlRleateVariables Motor speed, angle, memory frame size, etc.
A.2 Methods
Table 3 shows the main methods of the Reaction class in PAPA-MAN. The methods include ReadData, WriteData, ReceiveCommand, ISR_SynMotors, PPCommandDecode and CheckSensorSituation.
Table 3. Methods of the Reaction class
Categories Name Description
ReadData Read Data from external memory or sensor (order by address) using I2C
WriteData Write Data from external memory or sensor (order by address) using I2C
ReceiveCommand Receive PC command by wireless RS-232 Platform
Dependent
ISR_SynMotors ISR for motors sync. (for multi-motors operation) PCCommnadDecode Decodes the command from PC and make motion Platform
Independent
CheckSenorSituation Check the situation of sensor if in normal case or not
A.3 Implementation
This chapter explains the three major methods, WriteData, ReadData, and PCCommandDecode, which are implemented in the Reaction Class in PAPA-MAN. The implementation of the main operation is also shown.
A.3.1 WriteData( )
Figure A-1 shows part of the WriteData code. WriteData uses SetupActuatorCommand to send a command to the actuator control board. The actuator control board is a memory-mapping I/O connected to the central control board by I2C communication. The I2C communication functions are platform-dependent because they are defined in the PIC specific library.
//send data to passive component, address assign specific motor //data_low & data_high storge motor angle and speed
void WriteData (int address, int data_low, int data_high) {
addr=2*address;
i2c_start();
i2c_write(0xa0);
i2c_write(addr); //writing data to even address i2c_write(data_low);
i2c_stop();
i2c_start();
i2c_write(0xa0);
i2c_write(addr+1); // writing data to odd address i2c_write(data_high);
i2c_stop();
Figure A-1 Method of WriteData
A.3.2 ReadData ( )
Figure A-2 shows part of the ReadData code. The ReadData method is called CheckSenorSituation, and it determines whether pressure sensors are stable or not. The sensor control board is a memory-mapping I/O connected to the central control board by I2C communication. The I2C communication functions are platform-dependent because they are defined in the PIC specific library.
i2c_start(); //send start bit i2c_write(0xa0);
i2c_write(address); //send address i2c_start();
i2c_write(0xa1);
temp=i2c_read(0); // read data from address i2c_stop();
return temp;
}
//read data from passive component, adderess assign specific sensor int ReadData(int address)
{
Figure A-2 Method of ReadData
A.3.3 ISR_SynMotor( )
The ISR_SynMotor interrupts sub-routines to set the motor synchronization signal shown in Figure A-3. When the signal is low (pull = 0), the motors can be set up with a new command if a new command exists. The ISR_SynMotor is a timer ISR of the PIC in the central control board. The timer is set up for the main function. The ISR_SynMotor is a platform-dependent part of the Reaction class in PAPA-MAN.
{
pass=2; //reset }
} }
//ISR to check signal of motor synchronization, and reset the signal ISR_SynMotor()
PCCommnadDecode decodes commands from the remote center (PC). This method also sends actuator commands to the actuator control board. The code of PCCommandDecode is shown in part in Figure A-4. The method is platform-independent because the decoding command rules are defined by the user. The method is like a decision maker.
PCCommandDecode(char* command)
{
value[0]=command[0];
value[1]=command[1];
value[2]=command[2]; //decode command len=strlen(command);
if(strncmp(value,PLY,3)==0 && len==5) {
//reactions store in memory by frames (the sets of motor motions) //…
for(j=0;j<frame_max;j++) {
for(i=0;i<12;i++) //read frame {
burn_data[i*2]= ReadData(i2c_memory_address);
i2c_memory_address++;
delay_ms(6);
burn_data[i*2+1]= ReadData(i2c_memory_address);
i2c_memory_address++;
delaytime_else = delaytime % 200;
for (i=0;i<delaytime_count;i++)
}
high=(int)(motor_angle/100) + 10 * motor_speed ; low=motor_angle % 100;
pass=1;
while(pass==1);
WriteData(motor_num , low , high);
}
else if (command[0]=='t' && len==1 ) {
//command to PAPA-MAN stand up pass=1;
while(pass==1); //synchronization signal for(i=0;i<12;i++)
{
high=(int)(stand_angle[i]/100) + 10*control[i];
low=stand_angle[i] % 100;
WriteData(i,low,high);
} }
else ifelse if(command[0]=='a' && len==37) {
//control all motor speed //…
//…
}
else if (command[0]=='o' && len==6) {
//single motor control
motor_num=(int)command[1]-97 ; motor_speed=(int)command[2]-97 ;
//control all motor angle //…
}
//add the new command as your wish by defining the key word }
Figure A-4 PCCommandDecode method
A.3.6 Main( )
Figure A-5 shows the core operation of the reaction in PAPA-MAN. Before starting, the platform must be set up, including ADC, WDT, PSP, SPI, etc. The main infinite loop includes the methods above to implement the reaction in PAPA-MAN.
void main()
enable_interrupts(INT_TIMER2); //Setup ISR_MotorSyn enable_interrupts(global);
setup_wdt(WDT_OFF);
//…
while(1) {
command = ReceiveCommand(); //receiving command from PC
PCCommandDecode(command); //decode command and make actuator command
CheckSensorSituation(); //check sensor situation //…
} }
Figure A-5. The main() in PAPA-MAN