Go Down

Topic: PC to Arduino to Servo serial comms / timing - What approach to pursue ? (Read 474 times) previous topic - next topic


I have a LynxMotion robot arm which I'm driving by a Mega2560. It works fine. I can send controls to it's servo control board (ssc-32u) - it moves the specified servo(s) to the new angle over a given duration.

What I want to do is to send motion data from a PC (using python).  I've got this bit working too in part - in so far as I can send data from PC to arduino.  (I use an LCD display to verify).

My aim is to compute all the motion on the PC (see note below) , and provide that motion data to the arm in discrete steps - ie Updating the servos at a constant rate (eg at 25hz with rotations that last 0.4seconds)

The purpose of the Arduino in this case would be to convert the angles from the incoming PC data to calibrated positions for the servo driver, and also to perform additional tasks once the motion is completed...

So my question is this :  How to handshake/synchronise the data stream from the pc with the timing of the arduino/servos?

Option 1- Sync (PC is 'master')
I send the data from the PC at 25hz, and sync the arduino to the incoming serial data?  in which case The Arduino never needs to talk back to the PC (?)

Option 2 - Handshake (Arduino is 'master')
I make the arduino run the timings - It requests data from the PC each frame, receives that data, and  updates the servos - repeating that loop at 25hz

I'm not really asking about actual code specifics (at least not yet!)  - it's more about the general approach.. hoping that those with experience of this may be able to hilight pros/cons .

All advice gratefully recvd.

* FWIW  i don't much like the point-to-point motion of linearly interpolated poses we often see on robot arms driven by servos - On the PC I am describing a smooth curved path for the arms gripper and am using Inverse kinematics to determine each joints rotation, and it is this precomputed rotational data that I intend to send via the arduino to the servos at a consistent sample rate.


While not entirely understanding the reasoning for your 25Hz servo update rate, you mention a couple of things which lead to my answer:

... a Mega2560. ... - it moves the specified servo(s) to the new angle over a given duration.
The purpose of the Arduino ... and also to perform additional tasks once the motion is completed...
Both of these imply that the Arduino is in control of the servos for a given amount of time (or more to 'perform additional tasks'), so, once commanded the Arduino will be 'BUSY' for some period.
Whilst the PC could assume a task will always be complete in a stated time, this may be difficult to manage in the long term.

So... I think you are better off with Option 3 - Handshake, PC is master  :)

a) The PC sends a command string
b) the Arduino could immediately ACKnowledge this (so you are sure it's got it)
c) Arduino does it's stuff
d) Arduino signals DONE

If this leads to any unacceptable delay in 'streaming' commands, simply allow a buffer of 1 command (like ASYNC serial hardware does with the transmit register) so you can send:

i) PC: Command 1
ii) Arduino: ACK 1
iii) PC: command 2
iv) Arduino: ACK 2
v) Arduino: DONE 1
vi) PC: command 3
and so on...

If needed, the Arduino could reply BUSY instead of ACK if the PC tries to send commands too fast.
It would also allow 'variable time' commands to be done by the Arduino like 'HOME Axis A'



Thanks for your response TonyWilk. The option you suggest makes good sense.

I'd originally though of using handshaking, then dissuaded myself as it felt like: constant data, constant update rate - why bother to handshake.

My early attempts to sync the various parts just based on reciept of the data and presumed frequency proved to be difficult. Full Handshaking makes better sense, it will also produce more usefull code, and as you point out it can ensure other tasks of varying durations are managed in the same manner.

(The 25hz was just an arbitrary number i pulled out of thin air as an example.  I've no idea what the actual update rate will finally be  - considerably faster than 25hz I presume)

Go Up