Robotour 2008

After gaining experience in Robotour 2007, an international outdoor robotic competition, the team Short Circuits goes bigger. Enlarged by Ondra Luks from the past Eurobotic team MART, we are going to combine the team's experience with his love towards robust solutions.

The platform: November 15th 2007

After seeing the platform, we understood, why Ondra keeps telling us, that a wheelchair may be a perfect platform. Not a wheelchair I had expected, I must admit.

With the memories of our robot being torn apart because of a software bug last year, we plan to test in a simulator first. We opt for the Player(/Stage)/Gazebo robotic software platform.

Motor control: November 22nd 2007

Having a nice platform, we need to control the motor(s). Done. There is even a video of the first test of a motor control (avi, MSMPEG4v2, 612KB).

Gazebo has proved itself to be very robust. Very robust against our attempts to run it. I convinced it to run on FreeBSD and Debian Linux, both partially. I cannot use a simulated camera (any of them). It just crashes when I try. Ondra lost the battle on Debian. There is some mess with splitting the Player/Stage/Gazebo packages into small parts in the Debian repositories now. As a consequence, Gazebo is missing in there. We have to compile it ourselves.

I have created a Gazebo model of our platform (very car-like) as a plugin library and it is possible to hand-control it in the simulation.

Encoder on the motor

Having the motor running from the last week, we need a way to measure the speed. Ondra and Pavel have found a free space inside the motor, Ondra adds an optical encoder inside ... and it works like a charm! Pavel is testing Hall sensors for additional measurements.

There is also a new code which makes the simulated robot move.

I tried to convince the Debian box in the "lab" that Gazebo is a nice friend ... and it disagrees. No camera, no terrain model, no roads. It turns out, that:

Currently, Debian has ODE with OPCODE (for collision detection) turned off during the package compilation. The substitute turns out not to work for us. From the Debian changelogs it seems, that OPCODE is non-periodically switched on and off again.
From the Player/Stage/Gazebo mailing lists, it seems, that Gazebo works fully only with NVidia graphic cards. The computer in the "lab" has some kind of Voodoo magic inside (mostly a failure), my home Debian box has NVidia with the open source nv driver (partial success) and my FreeBSD computer is equipped with an ATI card (partial success). There may be some correspondence, but there is definitely more going on.

With all this Gazebo troubles, we consider using Stage (2D only) for simulations. What is a point of a 3D simulator without 3D features working, after all?

CAN: December 2007

Pavel has started prototyping the CAN bus we are going to use to drive our robot.

Electronic board(s): January 2008

Ondra has designed a board for motor control.

We are having (so far only theoretical) problems about a power consumption of any computer versus its computation speed versus its robustness versus its price.

Cash registers: February 7th 2008

Pavel has a news about a cash register(s) possibly driving our robot. It belongs to the "cheap, low energy consumption, a bit robust, slow computer" category.

Ondra is assembling the circuit board. We are discussing with Petr Wolf the applicability of SLAM in the competition environment with the computational resources we may have.

All the stuff: February – April 2008

I have been a bit late in writing, let me wrap it all up ...

Board computer

The current choice is a CappuccinoPC EZ3. It is a lowcost (because it is old), low power consumption, robust platform with a 1.4GHz Celeron processor and up to 256MB RAM.

CAN bus

Ondra and Pavel have been developing all the circuitry and writing the code. The communication between several boards which control the devices works prefectly.

Simulation

I managed to convince Gazebo to run on my new laptop (Intel graphics card). Cameras – work, terrain – works. If only a new fully how I did it ...

I also fixed our Gazebo model so that it, unlike all examples provided with Gazebo, works. (Note: When sending a device info, a timestamp has to be changed so that the Gazebo server does not ignore it as an old news.)

I have created a model with a simulated road (including junctions), so we can test the software (at least partially) in the simulation.

Player infrastructure

I wrote a skeletal driver for our robot. We still need to connect it with the low-level part.

I have also written a Visiir-based driver. It pulls camera images over the Player infrastructure and provides an information about a road. To test it, I wrote two client applications. One of them just shows the provided information about a road, the other uses it to steer the robot in a proper direction. This roughly corresponds to the algorithm used in 2007, but this time being nicely decoupled and possibly distributed due to the Player infrastructure.

Robotic weekend at Zadní Třebaň: June 13 – 15, 2008

We have spent a wonderful weekend with our robotic colleagues from the team RobSys and past team Sirael at a cottage at Zadní Třebaň. Robots included. Many thanks to Martin Dlouhý for his invitation and his wife for a tolerance.

We managed to put the following parts togeteher: Player clients, Player driver, communication over RS232 with a CAN hub and communication of the CAN hub with peripherals. As a consequence we can use playerjoy to control a steering direction and motor power. I will post a video once I get to it. We still have sime issues when sending messages one right after another.

We also made a fantastic code writing and revision failure:

for(i=0;i<com_len;i++)// printf("%d ",com_buffer[i]);
//    printf("\n");
printf("S %d \n",s_up.angle);

Why do we keep receiving messages multiple times? :-/

Long after the competition ...

OK, we did not make it. A wedding of one team member, final exams of the second and my physical dislocation from the team, together with the size and weight of the robot, killed the project. There were just too many things untested in the day of the qualification event and we did not manage to finish them overnight. As a matter of facts, not even during the competition day.