Arduino - simulink - cable driven robot

Hi,

We are some engineering students which are building a cable driven robot. The main goal of this robot is to achieve high accelerations of the end-effector such that it is visually impressive.

The main controlling unit will be an Arduino mega which will be programmed with Matlab/Simulink. Four motors will be controlled with an ESC (speed setpoint control) and encoders will be attached onthese motors. For accurate position control these encoders will have a high resolution (1024 ppr) and we'll run at a speed of around 3000 rpm. So the encoder input signal to the arduino will run at 51.2kHz.

Our first concern is the reading in of these encoder signals. By doing some research it should be possible to read in the encoder at this speed but we don't find some examples doing it with a Simulink programmed Arduino. Does anyone has some advice, knowledge or litareture which might help us?

So actually our main question is: what is the maximum order of magnitude of switching speed of the digital in- and output pins of the Arduino mega and how can we achieve this by using Simulink?

If things aren't clear, feel free to ask.

Thanks in advance!
Regards,
Nick

A 16MHz Arduino can read digital signals less than 20 usec apart and do something with them like control motor speed and still have some margin.

Use direct port manipulation and you can read/write/toggle port pins in one cycle. You may need more cycles to set up what to write or do with what you read but the port can change in one cycle.

I don't know or care to know Simulink but if it loads the board with code then all my bets are off at reading 51.2KHz blips and acting on them.

Why do you think that the motor axis position is the best information source? Isn't there a gear box, after which the rpm is much lower and the position is more precise?

Why do you think that the resolution must be so high? Taking into account mechanical tolerance of the actors, a 1% accuracy looks good enough to me. What's the full stroke of the actor?

Our application needs high speed (3000 rpm) around 1Nm torque. The only affordable option we could find is a BLDC motor which directly drives our application without any gearbox.

Our robot is designed such that we need to measure at least 0.5 degrees resolution to reach a desired accuracy. The first affordable and compatible encoder has a 1024 ppr.

The actual read takes 1 cycle but what matters is frequency of reads when you do all you need between.

It's not hard to read digital pins and blink leds by polling with loop() running at 67KHz, and that includes a loop counter task that prints. If I only run the loop counter, the speed is > 111KHz. With the counter and blinking led, > 80KHz. There is room to run an interrupt that only sets a flag and the regular code check the flag and do some processing at > 51KHz.

I have some example sketches I'm commenting before release is where I got those numbers. They are not guesswork.

If you need more cpu muscle, try a Teensy 3.6. It's got an ARM with FPU, 256K RAM, SD on board and OC's to 240MHz.

I would try to offload the encoder counting to a dedicated processor. Then the main Arduino can query that processor at 100hz instead of having to process multiple 51kHz signals directly.

Reading the encoder here is tightly tied to moving motors. Those tasks should be on the same chip. How many pins are needed for motor and sensing? Perhaps a Tiny45 or 85 could do the job for 1 joint of the robot. They're cheap by the dozen. Give it an order and let it run and send an ACK back when it's done or ERR back if it times out trying.

You mean like making your own custom servos? I don't think that's appropriate here. The robot is going to have to do coordinated movements. The multiple axes have to accelerate and decellerate together to arrive at the destination coordinates at 'impressive' speed. For me, that means operating all the motors from a common driver at reasonably high sample rates, like 100Hz.

MorganS:
You mean like making your own custom servos? I don't think that's appropriate here. The robot is going to have to do coordinated movements. The multiple axes have to accelerate and decellerate together to arrive at the destination coordinates at 'impressive' speed. For me, that means operating all the motors from a common driver at reasonably high sample rates, like 100Hz.

How to do that is have the coordinating controller send instructions to and read data from many dedicated parts.

SPI bus is bi-directional 512KB/s, short messages transmit real fast.
An SPI bus can only be short or slow and all the chips on it must be physically on it. In a robot I'd want the chips near what they're wired to, especially if they do any analog reads.

I have floated the idea of arranging MCU's in a serial ring to split a project between chips/boards and have them pass messages in a daisy-chain (multiple shift regs) that connects end to start. Each chip/board could be as far apart from the next as fast (115200 or 57600) TTL serial allows, 30 cm at least. That might connect sub-systems and a brain together then suppose the brain is a mega2560 connected to 4 rings, it could be on an SPI bus with as many other brains as needed.

There's also I2C.

If both speed and torque is required, hydraulic actors may outperform electric motors. As MorganS indicated, the achievable acceleration will limit the speed of the actors.

I still cannot imagine what kind of actor will turn at 3000 rpm and stop at 0.3° precision, in real life. If you mean a rotational servo (180-270°), a gear box will be involved.

Possibly it could accelerate to a maximum of 3000 RPM then decelerate to stop at a certain place.
Physics does still operate.

If I wanted fast motion where I could hide time spent not moving fast, I'd wind up springs to release or weights to lower. There's no pump or reservoir or hydraulic actuator, no seals to leak. A cheat would to start with springs would up and not rewind them.

You might do more with pressurized gas and pneumatics but there's seals and a pump or cylinder. Put a spark to propane and air mix in a Strong Container with a hole leading out, the bang could move or be something fast....