A systems re-engineering case study Programming robots with occam - - PowerPoint PPT Presentation

▶
a systems re engineering case study
SMART_READER_LITE
LIVE PREVIEW

A systems re-engineering case study Programming robots with occam - - PowerPoint PPT Presentation

Mar 21, 2024 39 likes •353 views

A systems re-engineering case study Programming robots with occam and Handel-C Dan Slipper Supervisors: Alistair A. McEwan Wilson Ifill AWE 1 The Problem 2 Re-engineering Platform Independent Model Legacy System Replacement Component

slide-1
SLIDE 1

A systems re-engineering case study

Programming robots with occam and Handel-C Dan Slipper

Supervisors: Alistair A. McEwan Wilson Ifill AWE

1

slide-2
SLIDE 2

The Problem

2

slide-3
SLIDE 3

Re-engineering

3

Legacy System Component Platform Independent Model Replacement Component

Behaviour Architecture

slide-4
SLIDE 4

4

LEGO MINDSTORMS NXT

LEGO Mindstorms NXT

 32-bit ARM7

microprocessor

 4 input ports  3 output ports  100x64 pixel LCD  Bluetooth  Power, 6 AA Batteries

Re-engineering

slide-5
SLIDE 5

5

Case Study

5

LEGO MINDSTORMS NXT CSP Program Structure Replacement Hardware System

slide-6
SLIDE 6
  • ccam

6

Case Study

6

CSP Program Structure FPGA Handel-C NXT

slide-7
SLIDE 7

Overview

  • Problem space
  • Project aims and background
  • NXT/Transterpreter implementation
  • FPGA implementation
  • Case study
  • Conclusions and future work

7

slide-8
SLIDE 8

Aims

  • Investigate the impact of modelling at a platform

independent level

  • Introduce two platforms using a common model
  • f concurrency

– Running a simple common task

  • Demonstrate behavioural differences and

integration issues between implementations

8

slide-9
SLIDE 9

FPGAs and Handel-C

  • FPGAs are “reconfigurable hardware”
  • Can be reprogrammed any number of times

unlike ASIC

  • Handel-C is a HDL making FPGA hardware

programming look like software

  • C like language augmented with a CSP model
  • f concurrency

9

slide-10
SLIDE 10

Handel-C Example

static macro proc C(chanB, chanA) unsigned int 1 value; value = 1; while(true){ chanA ? value; chanB ! value; }

static macro proc P(chanA, chanB) unsigned int 1 value; value= 0; while(true){ chanA ! value; chanB ? value; }

10

static macro proc P(); static macro proc C(); void main (void) { chan int 1 chanA; chan int 1 chanB; par{ P(chanA, chanB); C(chanB, chanA); } }

P C

chanA chanB

slide-11
SLIDE 11
  • ccam and the Transterpreter
  • The Transterpreter is a

modern virtual machine for a variety of commodity platforms

  • Interprets bytecode as
  • n the Transputer
  • Written as a C library

11

slide-12
SLIDE 12
  • ccam Example

PROC C(CHAN INT chanB, chanA)

INT value: SEQ

value := 1 WHILE TRUE SEQ chanA ? value chanB ! value :

12

PROC P(CHAN INT chanA, chanB)

INT value: SEQ

value := 0 WHILE TRUE SEQ chanA ! value chanB ? value : PROC main () CHAN INT chanA, chanB: PAR P(CHAN INT chanA, chanB) C(CHAN INT chanB, chanA) :

P C

chanA chanB

slide-13
SLIDE 13

13

  • ccam

13

Case Study

13

CSP Program Structure FPGA Handel-C NXT Transterpreter

Legacy System Component Replacement Component

slide-14
SLIDE 14

Drivers NXOS

NXOS + Transterpreter

  • Built on top of existing OS

– NXOS – set of C drivers and boot code

14

  • ccam

NXT Transterpreter

slide-15
SLIDE 15

NXT Architecture

15

Ultrasonic Sensor Light Sensor Touch Sensor Sound Sensor Motors (with tachometer)

slide-16
SLIDE 16

Peripheral Support in occam

  • Standard peripherals have support

– Analogue sensors – Motors – Ultrasonic sensor – Speaker – LCD – Bluetooth

  • NXT 2.0

– Colour sensor currently unsupported – 3rd party sensors partially supported – Using I2C

16

slide-17
SLIDE 17

FPGA Architecture

17

Ultrasound Sensor Light Sensor Touch Sensor Sound Sensor Motors (with tachometer)

slide-18
SLIDE 18

FPGA features

  • Light/Sound/Touch

– Implemented through ADC

  • Motors

– PWM – Tachometer – H-Bridge driver board

18

slide-19
SLIDE 19

Case study

  • Use implementations on FPGA and NXT
  • Common program architecture
  • Utilising a number of peripherals
  • Simple case study

– Follow a set path around the desk, changing direction with different speeds, (therefore angles) – Recognise the edge of the desk

19

slide-20
SLIDE 20

Path to follow

  • The path the robots should follow...

20

slide-21
SLIDE 21

Design of Experiment

21

slide-22
SLIDE 22

Robot Structure

22

slide-23
SLIDE 23

Process / Communication Structure

23

Control Code MotorA

MotorATach

MotorB

MotorBTach

Light Sensor reqMotorA

slide-24
SLIDE 24

24

  • occam
  • Handel-C

void main (void) { chan int 32 toMotorA; chan int 32 motorATach; chan int 1 reqTachA; par{ ADC_Read(); LightSensor(fromLight, reqLight); Motor1(toMotorA); Motor1Tach(motorATach, reqTachA); ControlCode(fromLight, toMotorA, reqLight, reqTachA, motorATach); } }

Main Implementation

PROC main () CHAN INT motorASpeed,fromLight, reqLight, fromTachA, reqTachA, reqTachB: ... PAR LightSensor(fromLight, reqLight) Motor1(motorASpeed) Motor1Tach(fromTachA, reqTachA) ControlCode(motorASpeed, fromLight, reqLight, fromTachA, reqTachA) :

slide-25
SLIDE 25

Control Implementation

  • ccam

PAR motorASpeed ! 70 motorBSpeed ! 70 reqLight ! 0 fromLight ? light WHILE light > 800 SEQ reqLight ! 0 fromLight ? light PAR motorASpeed ! 0 motorBSpeed ! 0

Handel-C

par{ toMotorA ! 70; toMotorB ! 70; } reqLight ! 0; fromLight ? light; while(light == 0) { reqLight ! 0; fromLight ? light; } par{ toMotorA ! 0; toMotorB ! 0; }

25

slide-26
SLIDE 26

Test Results

  • Path from occam implementation was a reference
  • Handel-C path was wrong

– Turning angles were different – Tachometer readings were therefore different – Overall system behaviour was incorrect

26

slide-27
SLIDE 27
  • Pulses after travelling 1000
  • Speed 100%
  • Speed 80%
  • Speed 80%

Further Tests

Robot Run 1 Run 2 Run 3 Run 4 Run 5 Mean Range Standard Deviation Handel-C 1247 1240 1239 1233 1232 1238 15 6.058052

  • ccam

1773 1783 1793 1814 1787 1790 41 15.26434

27

Robot Run 1 Run 2 Run 3 Run 4 Run 5 Mean Range Standard Deviation Handel-C 1213 1208 1209 1203 1206 1208 10 3.701351

  • ccam

1397 1417 1431 1415 1413 1415 34 12.1161

slide-28
SLIDE 28

Further Tests (2)

  • Distance travelled (cm)

– Speed 100%

  • Distances average the same over a vast range
  • Investigation is required into circuit and

differences in hardware

28

Robot Run 1 Run 2 Run 3 Run 4 Run 5 Mean Range Standard Deviation Handel-C 73.8 71.3 68.6 69.6 68.6 70.38 5.2 2.207261

  • ccam

70.4 70.4 71.0 70.6 71.2 70.72 0.80 0.363318

slide-29
SLIDE 29

Further Tests (3)

  • 1

1 2 3 4 5 6 7 8 9 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Voltage (V) Time (Seconds)

Average motor Voltage against Time when turning 1000 degrees

NXT Voltage FPGA Voltage

29

slide-30
SLIDE 30

Results

  • Voltage difference between hardware implementations

– Larger H-Bridge circuit

  • Braking only tested with ‘float’method

– void nx_motors_stop(U8 motor, bool brake)

30 30

Drivers NXOS

  • ccam

NXT

Transterpreter

CSP Program Structure FPGA Handel-C

slide-31
SLIDE 31

Conclusions and Future Work

Conclusions

  • Experiments demonstrate that programming same high-level

missions leads to different behaviours.

  • Therefore just modelling the high level behaviours is not

reliable enough for a systems re-engineering project

  • Modelling and verification methods are required for the

whole system Future Work

  • CSP model of system behaviour

– Translation to both implementation languages

  • Improve motor drivers to braking methods
  • More complex case study

31