We analyze the diagram from the block at the top left, the Battery Monitor, as I wrote in another post, the time is right for switch to using LiPo batteries without spending a fortune on our Robot, but it is better not damage them, and keep under control the level of charge, to do it I thought of using a PIC that could signal the charge status with an LED and remove power to the entire system if it falls below the minimum threshold, then saw, that there is a PIC why not allow the central system to control the level of charge? For this section I have a general outline and ideas on how to make it, but still have not made ​​a circuit to perform the first tests.
Continuing to the right of the diagram, there is the second block of supply, it is a switching circuit for supplying Step Down, whose purpose is to reduce the voltage that will arrive on the stabilizers to 5V on the other boards. This is because the main power will be supplied from a battery to 14.4 V, which voltage will be applied directly to the H-Bridge to drive the motors which work at 12V, while for the stabilizers that have to reduce the 14.4 V of the battery to 5V, are forced to dissipate as much energy as heat, resulting in faster discharge of the battery. To optimize power consumption will use the Step Down, thanks also to the experience and support of Guido, in this way the voltage which will arrive in input to the stabilizers will be of 7V with minimal energy losses in the form of heat.
The essential point of the schema is the BUS 485, I chose this for the interconnection between the various boards, the reason which oriented me to this choice of solution compared to other types of bus, is due to the fact that lately they’re more Robottari friends using this for their projects, and it seemed like a good idea now to make something that could somehow be shared with other projects, in addition to allow the exchange of experiences can also use other circuit solutions with minimal effort.
Moving on to the blocks in the lower part of the scheme, the sensor board as the name suggests, is one that will handle all telemetry and obstacle detection sensors. In order to accomplish something that could be useful to others I am trying to design it to make it as versatile as possible, although for reasons of cost I am forced to limit the use of sensors that I had in the drawers gathering dust. This is also the board that currently is in a more advanced stage of development, but I’ll talk more in detail in a later post.
The motor control will be assigned to the Motor Control block, with a board made ​​by my friend Stefano, which’ll cooperate for the development of software for PID control, this project follows the lines of the Guido’s project. I forgot to mention that this card is another reason that pushed me toward the use of BUS485, as Stefano has designed and built so (fortunately).
Finally, the control board of the Robot, as anticipated before, will be based on mbed, at least for the moment, equipped with a module WiFly for the transmission of telemetry data to a PC. On this part at the time, I have a few ideas but very confused, I do not think that will make things very complex as well as orchestrating the operation of various devices.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#include <i2c.h>
 
#define SRF02   0xE0            // Address of SRF02
 
/**************************************************************************
 * Initializes the device for operation in MSSP Master I2C
 *************************************************************************/
void srf02_config(void)
{
    OpenI2C(MASTER, SLEW_OFF);
    SSPADD = 0x63;              // 100khz BUS @ 40MHz PIC
}
 
/**************************************************************************
 * Performs the measurement by the sensor
 *
 * Returns the measurement made in centimeters
 *************************************************************************/
unsigned int srf02_read(void)
{
    int result=1;
    unsigned int measure=0;
    unsigned char measurement[2];
 
    result = EEByteWrite(SRF02, 0x00, 0x51);
    // Checking the outcome of the start of reading
    if(result==0)
    {
        // Awaits the completion of measurement sensor
        Delay10KTCYx(70);
        // Retrieve the measurement made ​​by sensor
        result = EESequentialRead(SRF02, 0x02, measurement, 2);
        // Checking the outcome of the sensor reading
        if(result==0)
        {
            // Writes the value read from sensor
            measure = (measurement[0]<<8);
            measure += measurement[1];
        }
    }
 
    return measure;
}

Below, instead of calling these new methods:

1
2
3
4
5
6
7
8
9
10
11
12

void main(void)
{
    ...
    srf02_config();
    lcd_clear();
 
    for(;;)
    {
        lcd_put_uint(srf02_read(),0,0);
        Delay10KTCYx(500);
    }
}

This sensor can be controlled through a serial or I2C, the choice of mode of control is administered through a 5-pin, which is connected to ground if you want to use the serial port, or left unconnected if you want to use the control via I2C. In this article I will speak of my experience with sensor controlled by a PIC 18F2620 I2C, and as you can see the management of the sensor is identical to that of a common I2C EEPROM. The details of the sensor and use them can be found at this link.

We begin to analyze the circuit diagram that is vary simple.

As you can see, in addition to the basic circuitry for the PIC (crystal, capacitors and resistor on MCLR) the sensor is connected to pins RC3 and RC4, respectively SCL and SDA, are used by the PIC MSSP module for communicating with I2C slave devices. Both of these pins are held at high level with two pull-up resistors from 1.8 K ohms, as required by the specifications of the I2C BUS. I also added a display to the scheme, in order to display the values ​​returned by the sensor.

Now let’s see the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

void main(void)
{
unsigned char counter;
unsigned int range=0, autotune=0;
 
    // PIC configuration
    config_system();
    // Get 6 faster read of sensor for autotune
    srf02_init();
 
    // Loop
    for(;;)
    {
        // Send to sensor a request to start a measurement in cm
        srf02_tx(SRF08, 0, 81);
        Delay10KTCYx(70);
        // Read the six register of sensor
        srf02_rx(SRF08, 0, 6);
        lcd_clear();
        // Write the firmware version of sensor
        lcd_put_uchar(srf02_buffer[0],0,0);
        // Write the value of unused regiter
        lcd_put_uchar(srf02_buffer[1],0,4);
        // Write the value measured from the sensor
        range = (srf02_buffer[2]<<8);
	range += srf02_buffer[3];
        lcd_put_uint(range,0,8);
        // Write the value of autotune
        autotune = (srf02_buffer[4]<<8);
	autotune += srf02_buffer[5];
        lcd_put_uint(autotune,0,14);
 
        Delay10KTCYx(500);
    }
}

As you can see also the Code (the full one can be downloaded from this link) is very simple, line 15 calls the function that starts the measurement of the distance in centimeters from the sensor. Then a delay waiting for 70 milliseconds have elapsed, the time needed to receive the echo farther, then reads the sensor 6 registers, storing the values ​​in srf02_buffer. As indicated in the guide of the sensor each register contains specific information as you can easily understand from the comments in the code, the part that interests us most is that the lines 25 and 26, where it reads the measured distance between the sensor and the ‘object that is in front. The display, educational purposes only, the code displays all other values​​, and as you can see the whole cycle is repeated every half second. At line 9 srf02_init() function is called, this does nothing but make six measurements in rapid sequence, as indicated in the specifications of the first 5/6 measurements are used to make self sensor calibration.

At first time, following the example on pages of documentation, I was going to read only the two registers that contain the measure of the distance, doing it this way but I had some strange measures, starting from a minimum readings began to increase by ten row and then start over. The smallest size was, however, be much more precise than that I get all 6 reading registers. Not finding useful information on this strange behavior, however, I decided to take the method of reading of all registers as more stable, and therefore as a system to use. If you have different experiences I would be curious to learn more then feel free to post comments with your experiences.

Soon I will also try to use the model SRF10, SRF02 which is managed similarly to, but being equipped with a transmitter and receiver capsule U.S. can maintain a lower minimum measure amounts to 6cm.

:: Download the complete code ::

This is an event dedicated to the schools, but there are also other initiatives in Robotic, also some mention of the many presentations on Arduino, held by a friend of Roboteck, the group also cited in the event program.

Among the events scheduled are:

• Explorer Junior
• Explorer Senior
• Robocup junior open league
• Robocup junior light weight league
• Robocup junior Dance primary
• Robocup junior Dance secondary
• Robocup junior Rescue primary
• Robocup junior Rescue secondary

If you are interested, you can go for more details on the official website of the event the link is as follows: http://www.romecup.org/

Established the system of locomotion, think about how to power the motors and the logic of the Robot. Always an issue of space, the first idea was to use 4 AA batteries and a battery holder than with springs, for the chance to change them easily. Doing a little calculations, however, we immediately see that this solution, as it can not go, because if we look at 4 common AA batteries 1.5V we have a total of 6V that are a bit short for a logic that operates at 5V, also using a LDO stabilizer, just because you are discharging batteries slightly to have issues. In addition you must consider also the H-Bridge, because of the internal circuits, which are applicable to motor down the voltage of 2.5V, would power the engines with 6-2.5=3.5V and a voltage too low for slightly engine that arise from 6 volts to say lose a lot of engine speed, considering that on a LF robot speed is an important factor, this is not a valid choice. Of course the discourse worse thinking about using rechargeable batteries that are 1.2 V per cell.

So here is the first problem, the H-bridge need also because the engines will be controlled in PWM, I would like to avoid choosing something different to L293, at least for now, so it remains for me to raise the voltage. There are two possibilities, increase the number of batteries, which would mean more space and more weight, or add a elevator voltage circuit, which means increasing the complexity and cost of the robot.
After we have reasoned slightly, ask for advice from friends Roboteck to have their opinion, which was almost unanimous to the use of Li-Po, it was actually a solution that I had never considered because of costs, that have changed over time, in fact for good NiMH batteries would cost about €4 so it will have to use six-element is the total €24, while watching one of the shops are of good modeling from 7.4V LiPo (2 cell 3.7V) 1800mAh (20C) at 20 €. Excluding the small price difference, what changes dramatically is the size and weight (80g difference).

On LiPo a clarification however to be made, batteries are slightly delicate, so they are managed wisely, you first need charger so special it’s better not to improvise because the LiPo could also explode, when they are used then you should not ever fall below a certain threshold voltage (3V per cell) after which the battery may also be damaged.
Without all these premises, also dictated by a number of recommendations received, I moved on to design the schematic of the power supply that is what you see in the picture.

Starting from the left the two inputs X1 and X2 are the connector of the LiPo battery from 7.4 V, first there is a resistive divider whose purpose is to reduce the tensionwhich is pulled at the point indicated by VBAT and sent to a ADC input to be measured, the purpose is to control the charge state of the battery during operation of the robot and, if necessary in case the voltage drops below a certain threshold, the splitter is used to reduce the tension that comes to ADC, considering that a fully charged battery the voltage will be higher than the 8Volt. The engines will be powered directly from the battery to the logic I added an LDO regulator (IC1) with classical configuration of input and output capacitors. In the circuit I just add a diode (D1) before the regulator to prevent reverse polarity, some may have noticed, however, that the engines, or better to the H-bridge goes directly to the battery voltage without going through the diode, this need my choice to avoid additional voltage drop to the engines, and are willing to sacrifice everything else that H-bridge electronics, even if damage is almost impossible, since the battery connector is polarized, however.
The next step will be to start putting the pieces together, ie to see the engines assembled on the support of vetronite that will also house the electrical power and motor control.

When connecting mbed to your PC, you will see a new removable disk, which is the flash memory of mbed where we will download our software, of course, if we look at the properties it is a few KB (never seen one so small USB storage;-)) as also indicated in the instructions leaflet, opening this disk is inside an html file which is simply a redirect to the registration page on the site of mbed.
Little information to fill out and you register for immediate access to the authenticated site, I saw that one side is given a serial number which should be relative to your mbed, but I have not investigated whether or not there is a direct link . The authenticated section remembers the Social Network, we first get to their home from which you can access other pages, all to share projects, libraries, references to other social networks (FB, Twitter, LinkedIn), show how other favorites users, and other features that I have not had the opportunity to explore, we are certainly not to the levels of FB, but there are several useful features, although at first glance, something is missing, such as could be a feed of the evolution of projects that you are following.

The highlight however is the “Compiler”, by clicking on this link opens in a new window in your browser development environment, from here you can manage their own projects, but you can also search, and import into your workspace all projects / public libraries created by users, just to point out another feature of navigation, when you meet interesting projects are available to access the shortcuts section of the compiler with the imports already configured to load the project you were watching.
The site still provides good documentation at this link there are explanations to start using the development environment: http://mbed.org/handbook/Creating-a-program.

When you create a new project is generated once the code to perform the flashing of one of the 4 LEDs on the card, but just do a tour of the various projects to understand how to make simple changes and begin making the simple play of light with 4 LEDs, maybe going to import some projects already.
In the short time I could dedicate yesterday I saw that there is also the possibility of using the USB connection, normally used to program the card, also for communication with the PC, just install a driver (the driver is only required for Windows ), and the connection will be seen as a serial, then using a terminal program (like HyperTerminal) and configure it as indicated on the site you may establish bidirectional communication with the PC.
To test how it works, just open the window of the Compiler, create a new project and write code that follows:

1
2
3
4
5
6
7
8
9
10
11
12
13

#include "mbed.h"
DigitalOut myled(LED1);
int main()
{
   while (1)
   {
      myled = 1;
      wait(0.2);
      printf("Hello World!n");
      myled = 0;
      wait(0.2);
   }
}

The standard output, but also the standard input is the serial port using printf then write directly on the terminal. Now just save the project and start compiling, after which the bowser start downloading a file “bin” with the name of our project. This file, which can be downloaded directly into the memory of mbed, our program is compiled, now just start the terminal program on your PC and then press the reset button on mbed, usually as a result we have the LED flashing, but will appear on the terminal “Hello World!” that will be repeated for each cycle of the code.

I must say, I was very impressed by the simplicity with which I managed to get this result, in other similar situations (PIC <-> PC) I spent much more time, and it required a much better knoledge of the object I was using, but in this case with an hour of “play” I came to this result.
Certainly the topics tested are very simple, instead I was interested in using the USB as host and I got lost in the maze of various documents found on the site, but this is certainly a more complex issue that surely requires further study, because it is the first time that I try and I also lack the basics.
I hope soon to have time to spend and begin to explore new things, I will keep you updated on the various experiences, but if in the meantime, you have a question or questions to be clarified, just ask, let’s see if I can help you