PSOC 4 Ball and Beam Control System, identification toolbox.

Sorry, ss.m won't run without the Control System Toolbox.

The Simulink model won't run with the following warnings:

I don't understand your model - I'm looking for things like angle, g, sensor gain/'offset/error but I can't see any of this.

MK

Hi  Mike, please erase the State Space block, there are two transfer functions the one depending on the BJ script is the Voltage Angle transfer function (I got it form identification), the other one is the trasferfunction for angle - ball position.

I can't run the script (don't have the Control Toolbox)  - can you enter the values into the Simulink model and then it could run without the script.

BTW - I think you modelling approach, although common, tends to hide all the insights that modelling can provide.

You should make an actual Simulink model of the physical system, where the angle of tilt applies acceleration to the ball, and then you integrate to get velocity, and again to get displacement.

The model can attempt to model the sensors correctly and ultimately you can include the resolution and lag of the ADC and the time step of the control loop.

MK

Can you work with simscape I can model it there I did it once.

I believe the IR sensors are more stable than the linear resistor because the contact between the ball and the rail is not uniform when rotating, I have filtered the sensors so I think they are good.

I don't have Simscape.

But you can model this system without.

Actually there are 2 double integrators (Bob Pease simplifies his description a bit and puts a servo loop round the motor which he doesn't discuss much)  - you have the motor - gearbox - beam system - your beam looks very massive so you need to take this into account. The second loop is the beam angle to the ball position.  So you have 4 integrators between the ball position and the motor pwm, and some delay in you control loop and some quantisation in the ADC.

Your step 1 model is 4 integrators  - nice and simple in Simulink - work out how to control that and your half way there.

I would almost certainly start (on the physical system) by making two control loops - one to control the beam angle and the second to control the ball by demanding beam angle.

MK

Awesome Ill work on it and get back to you!

Hey Guys,

A problem I had with the UART interface is that the microcontroller didn't have enough memory to work with the SPRINTF routine (it would consume most of the program memory) so I had to write an itoa function which I think can be another cause of the slow sampling rate so I remembered I read about Rossserial a while ago.

I was thinking should I try this out?

Rosserial On Cypress PSoC4 - JR

it is a Real time OS for embedded computing it should beat my UART interface speed.

any thoughts?

I havent used comparators so far! it definately sounds like an interesting solution I have to try it out. thanks!!

I may have missed something here - I'd thought you were just using the UART to dump acquired data to the PC. If the PC is in the control loop then you will find it almost impossible to get good control running under windows. If you are using  a USB adapter rather than a real hardware UART this will add lots of additional delay and timing jitter. If you are running at even 115200 baud then each additional character in your message adds 100us of delay - you can't afford to use ascii strings but should look at using a binary data format. Windows (or Linux) itself is not  a hard real time OS and will add even more delay and jitter.

If you run the control loop on the PSOC you can avoid all this.

MK