Control architecture design - help!

asked 2013-01-16 08:27:51 -0500

955 ●67 ●83 ●98

Dear all,

I am having a control architecture design decision to take and I was thinking some of you guys have probably already faced the same kind of problems. So here follows the description.

We are currently designing a mobile robot + mounted arm with multiple controlled degrees of freedom and sensors. In the initial configuration there are 10 positioning motors to control and we are considering modifications were this number would scale up. Sensors include an IMU (gyros + accelerometers + magneto) + kinect (for SLAM) + motor encoders.

I am considering the following architecture:

1. RTx: Positioning motors control
    - Achieved by a RT system (either Raspeberry Pis running an RTOS such as Xenomai or bare metal microcontrollers)
        -> let us call these machines RTx, with x=1,2,3… depending on the number of microcontrollers
    - Each of them controlling 2 or 3 motors with related encoders (not sure about the technology of the motors yet)
    - Fast loop: 200Hz

2. PC1: SLAM computation + IMU computation + fusion (SLAM + IMU + mocap) + high level logic (decide the robot’s task and deduct the motors desired position and speed)
    - Compute on a powerful machine (vanilla linux, no RT)
        -> Let us call this machine PC1
    - Onboard robot
    - Using ROS 
    - Slow loop: 30Hz

I know my framework needs to be scalable to account for more motors, more sensors, more PCs (eg. for external mocap). I was wondering whether there were typical or mainstream communication solutions used on robots (I know no brainer solutions do not exist but maybe there are typical ones that are often used). I have looked at papers related to robots architecture (eg. HRP2…), most often they describe the high level control architecture but I have yet to find information on how to have the low level communicate with the high level and in a scalable way. Did I miss something?

My main problem is to decide how to have the different RTx communicate with PC1. I am not sure which technology of BUS/netword to use to connect the fast RT machines ensuring the motor control with PC1. I have considered TCP/IP, CAN and UART. There may be other solutions, I do not know about:

1. TCP/IP: not deterministic but easy to put in place. Is non determinism a real issue (as it will only be used at at slow speed 30Hz anyways)?
2. CAN: slow, very reliable, targeted to cars ( have seen there are some exemples using CAN with robots but it looked exotic)
3. UART: if I had only had one RT machine for motor control I would have considered UART but I guess this port does not scale well with many RTx

Is TCP/IP really a no go because of its non-deterministic characteristics? It is so easy to use…

At the moment no solution really seems obvious to me. And as I can find no serious robot exemple using a specific reliable and scalable solution, I do not feel confident to make a choice. Anyone has a clear view on this ... (more)

edit retag flag offensive close merge delete

Comments

Another bus to consider is (EtherCat)[http://en.wikipedia.org/wiki/EtherCAT].

Thomas D ( 2013-01-16 10:56:47 -0500 )edit

add a comment

answered 2013-01-16 13:08:01 -0500

bit-pirate

2062 ●24 ●47 ●55

Welcome arennuit!

Nice first question! However, since it is not really ROS-related, you might get more and maybe better answers at general Robotics forums/Q&As, such as robotics.stackexchange.com. Anyway, here are my thoughts:

You already did the important step of splitting your system up into RT and non-RT areas. Now, the question remains how to connect them. To answer this, you need to figure out whether or not you need a hard real-time connection between both.

For example, if you plan to do joint trajectory interpolations and send each position/velocity command at hight speed to the motors, you might want to have a deterministic/low jitter connection to your motor control boards.

I'm not sure, what requirements you have: You stated, you want to determine (deduct) desired motor positions and speeds on the PC, but you also plan to run those control loop(s) at only 30hz. So, in case you don't do something like a fine-grained joint trajectory computation on the PC, I wouldn't expect you to need a real-time connection between your PCs and RTs. Hence, TCP/IP could be well suited for your system (as you stated, cheap and simple).

If however at some point you have the need for it, you can look into CAN[1] and Ethercat controllers for your PC. Be aware, that those controllers are often quite expensive. CAN has the advantage, that especially the devices/slaves (not the PC controller) are much cheaper than Ethercat, which on the other hand is more powerful (e.g. much higher bandwidth). Furthermore, you will need a RT system for your PC, such as Xenomai, in order to be able to run the fast control loops, which need to communicate with your RTs, in the real-time space. Setting up such a system and writing correct programs for it is also more difficult and time-consuming, than writing programs for normal user space.

[1] I don't think CAN is so exotic in the Robotic world. Companies such as PAL Robotics and Schunk are working with it. Also, we recently starting experimenting with it.

I hope, I could help you a bit! Keep us updated how your robot will look like in the end! :-)

Comments

Hello bit-pirate, your answer was very clear and very helpful. It definitely opens doors. Thanks a lot!

arennuit ( 2013-01-17 11:48:27 -0500 )edit

I'm happy, I could help. If you find your question answered, please mark it accordingly. Thx!

bit-pirate ( 2013-01-20 22:01:30 -0500 )edit

add a comment

Control architecture design - help!

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Control architecture design - help! edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Control architecture design - help!