Search This Blog

Monday, February 11, 2013

AMIRO - Autonomous MIni ROver


In a recent past I have been very active blogging about this project, which have occupied a portion of my free time in a rather pleasurable manner. After a period of pause I thought of bringing this project back to life, but not without providing an overview of what have been done.

My initial idea was to create a machine with a certain degree of mobility, able to perform actions according to a plan, and sense the environment while using this information to build a map of its surroundings.This goes into the domain of SLAM (Simultaneous Localization and Mapping) and is a rather ambitious domain to be easily explored without extensive knowledge, experience and a lot of time and resources to do experimentation and research. That wasn't quite the case for me, in my leisure driven approach, for the things I do outside the professional domain. I wanted to apply my technical knowledge and my passion for electronics while not getting serious enough that could affect the rest of my daily life, and still see this as a pleasure, not pain :)

The main steps were the materialization of the robot itself, putting together several components that I thought It would be the bare minimum to create an autonomous robot. In the links below is a sequence of the evolution of this project, since day 1:

http://creationfactory.blogspot.pt/2010/03/intelligence-on-wheels.html
http://creationfactory.blogspot.pt/2010/03/let-there-be-light.html
http://creationfactory.blogspot.pt/2010/03/cognition-on-wheels.html
http://creationfactory.blogspot.pt/2010/04/more-stuff-on-pipe.html
http://creationfactory.blogspot.pt/2010/05/almost-autonomous.html
http://creationfactory.blogspot.pt/2010/05/system-override.html
http://creationfactory.blogspot.pt/2010/06/sensors-are-never-too-many.html
http://creationfactory.blogspot.pt/2010/07/power-pack.html
http://creationfactory.blogspot.pt/2010/10/drastic-ne-improvement.html
http://creationfactory.blogspot.pt/2010/10/now-remotely-controlled-via-ip.html
http://creationfactory.blogspot.pt/2010/12/quadrature-encoder.html
http://creationfactory.blogspot.pt/2011/03/controlling-amiro-name-i-have-baptized.html
http://creationfactory.blogspot.pt/2011/08/amiro-more-enhancements.html

Once I had a working system I moved into writing some software to attempt to make it autonomous. It was a very basic reactive algorithm thought to make it move forward while trying to move away from obstacles as these appear in the way. The result was a bit cumbersome, so I left this development for a later stage. I ended up moving on with the development of remote control via Wifi, using a computer or an Android device. This enabled me to have some fun in the process. As of today I have a very sophisticated remote controlled car with telemetry displayed on the Android application, and a video camera to be able to see the way. This is nice, but I haven't forgot the fundamental goal of autonomous operation.

After more than 1 year without updates, I managed to get a time window to execute some of the developments that are on the pipe (having a baby and moving to a new job was the critical combination to leave this aside for a long time).

The next relevant thing I had waiting to be implemented was an addition to power management. In the original version of the robot there was essentially no power management, just a switch board through which the user could individually turn on and off some of the components of the robot (ESC, control board + Fonera, camera).

To open the door for more autonomous operation and extended battery operation, I had to design a module for properly controlling the power to the different components, enabling these to be switched on and off via software commands. The PIC18F2520 based control board had 4 available digital output pins, so at least 4 devices could be independently switched by a module receiving these 4 TTL signals.

Another motivation to build this module was the fact that previous state of the robot was a bit cumbersome regarding the power rails and efficient use of energy. For example the PIC board was being powered via a boost converter from 5 Volts to 7.5, where these 5 Volts would come from a buck converter connected to the 7.4 Volt LiPo battery used for the control electronics. This didn't make much sense as the PIC board (MuIN) could be powered directly from the battery without problems.

Another issue was the camera, which according to its design would require 5 Volts for the image sensor and about 9 Volts for the transmitter. As originally these 9 Volts were not available, the transmitter part was being powered directly from the 7.4 Volt LiPo battery used for the drive motor and servos. This resulted in poor range.

So, at designing this power management module I aimed at solving these problems as well.
Initially I considered using relays to switch on and off the different circuits (4), but by taking some measurements and perfoming calculations I found that each relay would consume about 65 mA or more. For my power budget this would be way too much, as together these 4 relays would consume at least 260 mA just for keeping the circuits closed.

Then I looked at the solid state approach. Galvanic insulation was not in this case very relevant, so a direct transistor based approach would be enough. To keep the power budget to a minimum I looked forward to use FET's instead of bipolar transistors as switches (there is virtually no current flowing across these in either of its conduction states). The challenge would be however to get a decent FET with low enough ON resistance, be of the P-Channel type (in the configuration of my circuit it would be more convenient to have low-side switching instead of the high side switching provided by the N-Channel FET transistors), and have a reasonably low cost.

After doing some research, I found the FQP27P06. This is a decent transistor with an average cost of 1 euro each.

http://www.sparkfun.com/datasheets/Components/General/FQP27P06.pdf

Its minimum on resistance is of around 70 mOhm, which is not bad. It can also switch loads up to 27 Amps and 60 Volts, which is well above my requirements. The only downside however is the high Vgs voltage needed to ensure it is fully on. In this case the 70mOmhs are guaranteed for -10 V of Vgs, but at for example 5 Volts it would not likely be enough. Experimentally I found that the 7.4 volts of the batteries would keep the transistors on without substantial added resistance.

In order to provide this drive voltage I had to add some bipolar transistors to the circuit in order to get the appropriate level translation, considering the 5 Volts TTL signals received from the MuIN PIC board. As such I select the popular 2N2222 with a 4.7 K resistor in series with the base-emitter junction of the transistor. This would limit the current to just about the necessary to keep the transistor in saturation (about 1 mA in each transistor). A 10 K resistor was added between the battery voltage and the collector, to limit Ice when the transistor is conducting. The voltage that drives the gates of the FETs is obtained from the collectors of the bipolar transistors. When the later are in the saturation region, the voltage at the collector is nearly 0 Volts, which in respect to the source pin of the FETs corresponds to roughly -7.4 Volts (the approximate voltage of the LiPo battery). The drain pin of the transistors connect directly to the positive rail of the loads.

In an attempt to put together circuits initially scattered in individual boards, some care was taken to include for example the voltage dividers used to measure the voltages of the batteries, in the same board.
As the camera didn't had a proper audio circuit (it had a very basic single transistor amplifier and a electret microphone that practically did not produce reasonable sound results), I thought of inserting an audio preamplifier and an electret microphone into this board. As such I selected the LM358 which I had used in a previous microphone preamplifier project. This device offers very reasonable results and yet it is quite inexpensive.

To solve the camera power issue, I added the boost converter that was being unnecessarily used for the MuIN board in order to produce 9.5 Volts. The boost converter is the following:

http://www.pololu.com/catalog/product/799

For the 5 Volts input of the camera (the CMOS sensor itself) I have added a 7805 regulator to the circuit. This is also used to power the audio preamplifier.

As such the circuit diagram is the following:

And below an overall diagram showing the modules, power rails, control,and how these are connected together:

Both buck converters shown in this diagram convert the input voltage which should be around 7.5 Volts, to the 5 Volts necessary to power the Fonera and the servos. Each is capable of a maximum of 3 Amps of load, and in spite of being different boards (one more compact than the other) both are based around the same LM2576S chip.

Initially the plan was to be able to put the entire circuit into a single rectancle of veroboard pcb. However I soon realized that there wasn't going to be enough space for all the components and links in the same board. As such I ended up assembling a smaller second board just for the FETs and driver transistors. I ended up stacking the two, which resulted in terms of occupied space:

For basic protection the Electret microphone was wrapped around heatshrink tubing:

The entire block with a much cleaner look if compared to the previous setup:

The connection to the MuIn board, where the 6 pin connector in the foreground is used to send the control signals to the power module:

In terms of software, so far only MuIn firmware changes and Fonera software were necessary to support this development. In the Android application I kept it transparent for now. This basically means that currently the Fonera daemon detects when a connection is established and causes the ESC control pin to go high. In turn this activates the ESC and the power to the servos. The camera is activated when the Fonera software have completed booting. The Fonera itself is started shortly after MuIn is booted up. There is a delay implemented in MuIn to cause this to occur in sequence. MuIn itself is started when the user presses the push button. This button shorts the FET source and drain pins causing power to go to the module. Once the module is powered, it raises the level of the pin that controls the power to the module itself, causing the FET to conduct, allowing the user to release the button.

No comments: