I want in this subject to discuss about programming robots in general. I believe that under actuated robotic is the future because most of complicated computations (trajectory optimisation for instance) is done by nature.
Most of actual robotic softwares help to make scripting or multithread scripting to compute trajectories etc.
For my biped project, I want to make “underactuated programming”. It means speaking about event manager, filterings of output, study interferences between mechanics and software.
It induces also multirate programming. Some of basic algorithms have to play every 10ms, others every 1s or every 10years and also every 1us (sound).
Most of time, I use the scripting tools to approach this kind of programming but it is not made for.
I think you raised a very important point here. However I’m not sure exactly what under-actuated robotics would specifically implies in term of programming. Event manager or filtering are well known programming paradigms running in other domains for long time. Could you give me an example of what you would call “under-actuated programming” that would be non-trivial to develop using classical programming approaches?
Concerning Pypot, it has been designed form the beginning with the aim of facilitating the writing of simple behaviors (what we called primitive) and - more or less automatic - combination for creating much complex behaviors. Those primitives can, as you are asking, run at different frequencies. But more generally, a core idea was to rely on a high-level language such as Python so we can build upon their existing libraries. For instance, writing an event manager in Python (e.g. using Event objects) is rather straightforward.
Recently, Jibo’s developers have announced that you will be able to directly program their robot using javascript and Node.js or even drawing behavior trees. Such a graphical way of designing complex behaviors without having to focus on the low-level and parallelisation complexity seems to me like the way to go. Having the possibility to graphically sequenced, combined, filtered your Pypot’s primitive would be a huge improvement!
Thank you for the answer.
To illustrate under-actuated robotics, I can take the simplest under-actuated robot : the Acrobot simulated or Acrobot real
It is a vertical (with gravity) double-pendulum with only one actuator at the elbow (there is no motor at the shoulder). The challenge here is to control the elbow so that the double pendulum is vertical.
It seems quite impressive but looking at this course, it becomes possible… In simulation
I think that the software which makes the programmation of this behavior easy is the good one. In same course, the way to make a biped robot is also explained.
To be more precise, the clue here is to see the acrobot in a phase plane. The state of the system is theta (the angle between the extremity of the arm and the gravity) and its derivative thetad.
If you want the arm to be vertical, a stable point must be theta=0 and thetad=0.
The control strategy I discovered in this course is the dynamic programming.
Cut the phase plane in several parts to obtain a grid theta(i), thetad(j). The objective is to find what is the angle of the elbow joint to get from a theta(i) thetad(j) to another one (discretization of the phase plane)
The way to solve this map is to go from the stable point and to find the optimal command to go from the nearest state to the stable point and to go on recursively. I think developmental view of this system could be interesting.
If you want another stable point, another map is needed…
In a way, this is control by the memory… In simulation again.
Making this as a graphical programming is a super challenge, and is a good challenge I also think. In aircraft control we ONLY use graphical programming : SCADE. With SCADE you can do easy things such as complex numerical filterings or signal processing in “two clicks” but writing script is much more difficult. With scripting tools, scritps are of course simple but filtering induces mastering sampling rate (to convert analog filters to digital ones). It is not possible to program an Acrobot with SCADE.
I wish you see the point. I think that Pypot is on the good way to do this because you really want to master the sampling rate. Controlling an Acrobot with Pypot using graphical programming “in two clicks”… An interesting challenge I think
Ok I think I better understand what you are trying to do. Actually, with @Clement we are working on the Explauto library (cf. this post). You can also find here an example of an under-actuated pendulum and how it can be controlled (an exemple can be seen here).
That’s very interesting! It makes me even more convinced that this is also the way to go for robotics.
I have built an architecture which is very efficient to control a dynamic robot and most important, make research on it. As far as possible, I try to use the builtin Python classes and Pypot. Here it is the dictionnary.
The principle is based on dataflow synchronous control (like LUSTRE (SCADE) but in much weaker)
I instanciate a pypot.robot from a .json file
I instanciate the sensors I need and launch the reading tasks.
To the robot, I attach a primitive which is an infinite loop until a given duration (30s for instance)
The primitive is as follow:
duration=30
DT=0.01 #sampling period at 100Hz
flow={}
Recflow=[]
flow["t0"]=time.clock() #start of the loop
while T<duration
t=0
flow["t"]=time.clock()
flow=get_sensor(flow,robot)
flow=numerical_filter(flow)
flow=controller(flow)
flow=refresh_monitoring(flow,QTwin)
flow=set_actuators(flow,robot)
# wait the end of the sampling time
while t<DT
t=time.clock-flow["t"]
flow["dt"]=t
# let's record
Recflow=[Recflow,flow]
save(RecFlow,"toto.rec")
All the function called, work with flow dictionary which is saved at each time step.
On the other side, it is very easy to analyse the file toto.rec with Python to analyse what happened, is the sign wrong, the system did work or not, if the CPU load is not saturated, what is the weather inside the motors…
Moreover, instead of controller function, it is possible to call a finite state machine to handle hybrid systems (like a biped for instance)
Since I have this structure, I know what I do, and it is easy to understand (no useless complexity)
I think it is a good base to make “clean” programs. What do you think ?
This seems really interesting! From what I understood the idea is to store the “state” of the robot at each time step. Is that right?
Then you use this information to control the robot. Can you give an example of how you would do this using your recflow dictionary for that?
I don’t know this paradigm. Can you give me more details? As a more general comment with @Clement, we are more and more interested in using “orchestration” langage paradigm to compose robotic behaviors (see pypot’s roadmap).
You should be careful. Basic sync loop on poppy creatures are running at 50Hz by default! You can obviously change that directly in pypot code (maybe you already did that).
The idea of synchronous dataflow is like a chain of plants aside a river. The first plant put some data in the river. The next plant will take the data in which they are interested to produce other data for the following plants, etc.
The phenomenon is done with a constant period.
Moreover, the river is a loop. so each plant can pick up data from the last turn (for first order algorithms for instance)
The fact I store the flow at each step in recflow is only for analysis. I can deactivated this storage. I can also store 1 of 10 flows to avoid storing too much data. I use matplotlib to view all data function of time.
What is useful is that we can deliver in the flow all intermediary variables for calculation very easily.
I watch about orchestration (the TEDx conference to have a global view). I think it is very close since he said he was inspired by aircraft flight computers which are done like this. There is only the “anticipation” part I do not completely understand.
For the sampling period, the “IMU” I am using delivers data at 100Hz. For the moment, I keep this sampling rate but maybe in future I will reduce it.
You need multiple loops to make parallel tasks.
Here, the flow is global for all tasks and each task is done every dt.
To synchronise multiple tasks, you use the flow.
This kind of architecture is hard real-time architecture (dt is known and sure) if dt is small enough with respect to your system dynamics.
In Lustre, you can manage plants which activate not every 20ms but every 120ms or others and deliver packets in the flow. It can be useful for high CPU load tasks (image processing for instance)
But here I don’t know how to do this (maybe 2 flows?), I have no need for the moment.
