Group Actions
Engagement
  • Author Author: shabaz
  • Date Created: Date Created
  • Views 1370 views
  • Likes 9 likes
  • Comments 24 comments
Related
Recommended

Building a Robot! (Simulated)

shabaz

After having built a couple of small wheeled platforms (a crude attempt called XMP-1 and a slightly better one called XMP-2) I was curious what simulation tools were out there specifically geared toward robotics design.

This is just a quick summary of one of the simulation tools that are available, called Gazebo.

 

Gazebo was incredibly easy to get going – a single command line will install it onto Linux, and when run it is easy to add bits and pieces from the toolbar and get going.

I’ve yet to work through the tutorials but I’m hoping to eventually simulate XMP-2 so I can write better code easily.

 

Here is a screenshot of Gazebo, and a quick video showing some basic physics, pushing the robot into coke cans.

image

 

Video:

 

More complex movements are possible too. Here is a robot gripper with torque being applied to part of it:

image

Video:

 

The simulation includes gravity and friction and many attributes are configurable.

The models can be created in XML files, and the tutorials look comprehensive.

The example below from a tutorial shows a snippet of a robot, where a box-shaped chassis is needed. The <pose> element contains the position (xyz, and orientation in three dimensions). The <collision> and <geometry> elements contain a <box> element which defines a box of size 0.4x0.2x0.1m in this example.

Usually they are the same; one element is used for the graphics, and the other is for the collision-detection algorithm to use.

image

 

The simulation can be connected up to real hardware or software through the use of an application programming interface (API), so it is possible to test robotics software before you've built the hardware, or you can interface your sensors and start programming movements.

It all looks extremely interesting!

Check out the second part by clicking here, which goes into detail about how to construct a model (based on a real hardware robot called XMP-2) and how to control it using external stimulus.

Parents Comment Children
  • in reply to balearicdynamics

    Hi Enrico!

    I tried getting the API to work, so it could be possible to connect to external hardware to move the robot simulation. It did function, but I did not get around to connecting to external hardware so instead I just modified the code so that it would check a file, and if the file had been modified the robot simulation would act on the instructions in the file and move the robot in the simulation forward. This worked well, so it would be straightforward to have code that would read from real hardware and write an instruction to the file.

    The video in the blog post shows the file method, it was a very basic demo though just to see if this could work.

     

    It is nice that the Gazebo software automatically takes control of all the physics, i.e. mass, forces etc provided the model contains these, so in theory it should show if motors etc are powerful enough, and the effect of (say) accelerating towards an object to push it away, compared to being close to the object and then trying to push it, etc.

  • in reply to shabaz

    What sounds strange to me (100% ignorant) is how can I interface hardware. Should be followed some kind of standard? What if a custom hardware is used, as usually occur on specific development projects? I am curious to this aspect.

     

    Enrico

  • in reply to balearicdynamics

    Good point, I'm not sure if a standard exists!

    Gazebo doesn't have a direct hardware API (from what I can tell) just a software interfacing API, so on Linux possibly the easiest way is to either use a USB attached device like a serial port, and then have a short custom program to read from (say) /dev/ttyUSB0 (or whatever the USB serial enumerated as), and then based on the read value, either write a command to a file (using usual file write API in the programming language chosen), or instead have some nicer communication scheme, I just used the file write method above because it was quickest for the test.

     

    So, the hardware would need (say) Arduino or something to translate the buttons/sensors etc and if desired any outputs (e.g. real motors to compare the simulation to the real world response) to the serial UART.

     

    It would be interesting to have a standard for robotics inputs and outputs, like event time and end of event to capture durations as well.

    Maybe this sort of thing exists, ordinarily of course the control is a tight processing path in a microcontroller, from input hardware (button, sensor etc) processed through to output device (motor, servo), but here this is not the case since we want to pass it into the simulation!

  • in reply to shabaz

    Shabaz, you response is really helpful but I have a strange perception, just based on your experience. It seems that this system (say) can - in someway with a file or something else - will receive the physical behaviour and compare it with the model. That's great but what about controlling the physical stuff in a testing environment to adhere it to the model? Is this possible? Has this a sense ?

    I mean, in the case Physical Vs Simulation, this means that you have already built the hardware... Almost late to review the project, in theory based on the simulation model. There is a bit of confusion on this part or I am wrong ?

     

    Enrico

  • in reply to balearicdynamics

    Hi Enrico!

     

    (On mobile keypad so will keep this short) the system allows for complete software simulation, or you can inject stimulus from a second process (I did that with a file just as a test) and that means it is possible to inject some stimulus from the outside world if you wish to. It is not necessary, but could be interesting sometimes to see the effect in the virtual world if (say) the robot encounters sensor stimulus from the outside world, etc.