Khepera II FAQ

( external translation in Serbo-Croatian)

Q: My Khepera/Kameleon/Koala does not answer to remote commands.

A: The main problem consist in checking whether or not your serial line works.

First, make sure that no program is currently grabbing the serial port (MATLAB®, LabVIEW®, …).

Open a terminal program (like Hyperterminal or better Tera Term http://hp.vector.co.jp/authors/VA002416/teraterm.html ) and set it up for the appropriate COM port, baud rate (look in your manual correspondence between start mode and baud rate) and settings (8 bit, 1 start bit, 2 stop bits, no flow control, no parity).

Make sure to “connect”. Now press the reset button you should see, for instance for a Khepera, the following text:

ROM of minirobot KHEPERA, Edoardo Franzi K-Team S.A. October 22, 1998 Rev. 5.01
Serial Communication Protocol

Try typing ‘B’ and carriage return. You should receive a response like b,5.02,5.01 as

If you do NOT see this, you may have a serial port problem:

make sure your cables are properly connected (do NOT use NULL modem cable).

check the port number and speed, and verify the Khepera jumpers.

for the Khepera: check that the charger interface, Tx Led flashes. If yes, check the cable to your PC. If not, check the cable Khepera / charger. If the cable is OK, then contact us.

for the Koala: check that the Tx LED on Koala flashes, if not then contact us. If you receive but cannot send anything to the Koala, please check the serial port switch (p8 of Koala User Manual). If you are using the Koala DTE serial port, you need a NULL modem cable (DTE pinout is given in the Appendix B of Koala User Manual, p44-46).

for the Kameleon: check that the Tx LED on Kameleon flashes, if not then contact us.

Q: Why Khepera?

A: The robot is called Khepera because of an internal old story: at the beginning, the developers called the robot “Cafard”, which in french means beetle. The boss at this time was not happy about this bad name and found out a Egyptian god with the head of a beetle called Khepera.

Q: Why are Khepera so expensive?

A: Khepera cost is due to its features:

  • miniature size.
  • 32bit processor on board.
  • reliable, miniature mechanics.
  • precise encoder (one pulse each 83 micron).
  • 30 mn battery autonomy.
  • free support.

Moreover, Khepera offers many assets:

  • many hardware modules (gripper, camera, radio,…).
  • a large community of users with KNews, our mailing list.
  • a free cross-compiler.
  • a realistic 3D simulator Webots http://www.cyberbotics.com/.
  • free plugins for SysQuake, MATLAB®, LabVIEW® & Saphira.

Q: What can I do with my Khepera?

A: Concerning the software, there are mainly two ways to use the Khepera:

(1) By cross-compiling C programs that can be runned on the Khepera processor. By this way you can write a program like:

do
{
for( i=0; i<8; i++)
{
Sensor[i] = sens_get_reflected_value(i); /* Read sensor activation */
}

… your treatment of the sensory information

for( j=0; j<2; j++)
{
mot_new_speed_pid(j, Motor[j]); /* Set motor speed */
}
}

while (TRUE);

This program can be compiled for the Khepera processor, downloaded into Khepera and executed. The big disadvantage of this approach is that you cannot monitor in a good way what is running on the Khepera (no monitor on it….).

For people who want to operate in this way we can provide a package with the Khepera libraries for the GNU C public domain compiler.

The documentation and the libraries to complete the GNU C public domain compiler cost 300.- Swiss Francs.

(2) By sending commands to the robot via a RS232 serial line. The robot has a remote control mode that make it possible to send to him commands like:

N

and the robot answers

n,1,12,386,0,12,62,1023,0

where all the numbers are the values coming from the proximity sensors. On your computer you can process these values following your algorithm and have, as result, the values of speed that you want to apply to the motors. To send the motor command to the robot you can simply send on the RS232 the command:

D,3,-2

and the robot will apply the speed 3 to the left motor and the negative speed -2 on the right motor. Then he will answer:

d

telling that the order has been executed.

This second way to control the robot by using RS232 ascii commands is very powerful because it make possible to control the robot from a program running on your computer, in a very simple way. The progam running on your computer can be a pure C program that you have written yourself and that is able to manage the RS232, or can be a MATLAB®® module that sends and processes the commands on the RS232, or a LabVIEW®® module doing the same operations.

All what these program have to do, is send and process strings on the serial RS232 line.

The advantage in using LabVIEW® is that you can create a visualization tool in some minutes. The same in a C environment would take much more time and competences. The disadvantage of the LabVIEW® environment is that this environment is quite slow in execution. Moreover, LabVIEW® is very general, and do not has all mechanisms that you can find on a specific environment like a robot simulator or your soft.

For a high level of complexity it is better if you create your own tools (your C program that control the robot and display what you need to display).

Q: One or two motors do not answer to command and goes very hot.

A: Most of the time this problem is due to dust or hair that goes inside the gear. The first action is to look from the bottom of the robot inside the gear and see if there is dust (hair or other) that can be extracted. If not, the dust could be more internally and it could need a cleaning and check from us. If you cannot correct the problem, you should think about sending it back to K-Team.

Q: I heard a popping sound while charging.

A: ATTENTION! A popping sound while charging strongly suggests battery leakage, and battery acid spray can quickly rust anything it touches. It might happen because you overcharged the Khepera. Khepera should keep working (at least with a cable) until the acid eats away the PCB, but then it will be too late to save them!

PLEASE when sending it back to K-Team, separate the bottom part and the top part of Khepera and keep the bottom part upside down in case any more acid leaks out!

Q: My accus look rusty.

A: ATTENTION! Rust on your accus strongly suggests battery leakage. It might happen because you overcharged the Khepera. Khepera should keep working (at least with a cable) until the acid eats away the PCB, but then it will be too late to save them!

PLEASE, before sending it back to K-Team, separate bottom and top part of Khepera and keep bottom part upside down in case any more acid leaks out!

Q: Software plugin for Khepera does not work. I have Khepera BIOS < 5.0.

A: The only solution is to upgrade your Khepera. Please contact us.

Q: I have some doubts on the odometry of my Khepera. How can I test the precision of my Khepera?

A: Simply set the wheel position to 0 (command “G,0,0”), then make it go forward (“C,2000,2000” for 16 cm) and, when arrived, go back to 0 (“C,0,0”). Make several times so and look if the robot comes back at the same place or not. This can already give some indications about the robot quality.

Q: I need to know the precise distance between the wheels?

A: Set the position of the robot wheels to 0, set the speed to -2,2 (turn on place) and let the robot turn 10 times on itself. Stop it exactly when it makes the 10th revolution and look the incremental encoders values (command “H”). Knowing that the robot made 10 revolutions you can say that the wheel should have moved 10*Diameter*PI. For more precision, you should measure exactly what you have on your particular Khepera on your particular ground.

Q: I want more precision in my displacement. How can I do?

A: By adjusting the speed profile, you will be able to reach the maximum precision.

Q: Can I build a Khepera extension turret?

A: You can easily build your own turret.You will find below links to the document on the Khepera extension bus, alias the K-Bus. The bus includes three analog input, four digital ouptu and four digital input and the SPI communication protocol (84 kbps).


http://ftp.k-team.com/khepera/documentation/KheperaBus.pdf

http://ftp.k-team.com/khepera/documentation/KheperaNET.pdf

Q: Why Khepera II is cheaper than Khepera?

A: Khepera I was much difficult to mount, contained expensive obsolete electronic components and was produced in smaller batch, hence Khepera II is cheaper but also better than Khepera I due to its additional features:

  • Flash memory to reprogram the robot instead of UV EPROM.
  • Robust body.
  • Current consumption sensor.
  • New batteries for larger autonomy (60mn instead of 30mn).
  • Faster CPU speed (26MHz instead of 16MHz).
  • New IR sensors for improved obstacle detection (10cm instead of 5cm)).
  • Bigger memory capacity (512 Kb instead of 256Kb).

Q: What are the differences between Khepera and Khepera II?

A:

  • FULLY COMPLIANT WITH ALL KHEPERA EXTENSION.
  • NEW flash memory to store your programs or upgrade your BIOS (512KB).
  • NEW power consumption monitor.
  • NEW body for a more robust robot.
  • IMPROVED Autonomy: now over 60 minutes.
  • IMPROVED IR sensor range: now up to 100mm.
  • IMPROVED serial port speed: now 115.2 kbps.
  • IMPROVED RAM: now 512kb.
  • IMPROVED CPU Speed: now 26MHz.

Q: Why K2D does not fit in Khepera II?

A: K2D does not fit in Khepera II because K2D is not conforming to Khepera Bus Specifications.

You can find these specifications at http://www.k-team.com. However, to use a K2D on a Khepera II, you can simply cut the extra pin 24, labeled delta_cap in the previously mentioned document. Of course, the warranty will cover any damage during this operation.
LabVIEW®

Q: I receive my Khepera but LabVIEW® is not included.

A: LabVIEW® is a product of National Instruments ( http://www.ni.com ) and you should contact them to order it. The fact to order LabVIEW® locally (and not from K-Team, which could be possible) gives you a better local support from National Instruments. National Instruments does not like that we buy a package from the swiss branch and then the support is given by your local branch. Moreover, please note that:

  • LabVIEW® can be useful but it is not necessary to use Khepera.

    LabVIEW® controls Khepera using a very simple ASCII protocol on the serial line. This protocol is documented and can be implemented easely in your favourite anvironment that you already use (we have Khepera users working on many machines and many environments, like LISP, MATLAB®, Mathematica etc.

    The advantage in using LabVIEW® is that you can create a visualisation tool in some minutes. The same in a C environment would take much more time and competences. The disadvantage of the LabVIEW® environment the fact that this environment is quite slow in execution. Moreover, LabVIEW® is very general, and do not has all mechanisms that you can find on a specific environment like a robot simulator or your own soft.

  • You have several version of LabVIEW®. The only LabVIEW® functionality you really need for Khepera is the serial communication. This means that you do not need to buy special drivers for data acquisition.
  • LabVIEW® is usually quite expensive (starting around 1500$)
  • There is a VERY cheap student version of LabVIEW®. The student edition is published by Prentice-Hall. You can have more infos at the page:

    http://www.ni.com/academic/?readformedu_lvse.htm

    The only limitation of this edition is that it is an old version.

Q: The gripper does not work: it does not stop when it feels a resistance.

A: It is true that the “close gripper” command (“T,1,D,1”) does stop automatically when it feels a resistance. However it often happens that users unknowingly call this command repeatedly which WILL cause problems. For instance:

void grasp()
{
if (isGripperOpen())
{
send(“T,1,D,1”);
}
}

is correct, although that fact that the grasp() routine does not return a value prevents you from knowing the grasp was successful or not. In addition, it is not clear what isGripperOpen() does: what does it return if the gripper is holding an object and is neither completely open nor closed? Depending on how the calling function is written it is possible that the software is calling the grasp() routine repeatedly, which can explain why the gripper no longer works properly.

Q: The gripper does not open and close properly, or at all.

A: The symptoms indicate that the belt inside the gripper has jumped off the pulley. It is a somewhat delicate operation to put it back, but with care you can do it yourself.

1. Disconnect the power to the gripper

2. Remove the 6 screws that hold the upper PCB in place

3. Gently lift the part of circuit next to the arm motor. There is another motor inside the arm with a pulley at one end that moves the gripper’s “fingers”. You should be able to see if the belt has jumped off the pulley or not.

4. If the belt is still on the pulley, you have another problem, so put everything back together and call us!

5. If the belt HAS left the pulley, make sure the gripper is fully CLOSED, then hold the motor with your right hand, while holding the gripper closed with your left hand. Manipulate the motor to get the belt to fit back into the groove on the pulley.

6. Once you get the belt back on the pulley, replace the motor in its normal position

7. Replace the PCB, being careful that the flex circuit is properly placed inside the arm. Don’t make any sideways movements while replacing the circuit. (???)

8. Replace the 6 screws.

Q: Why do I get no video signal?

A: Most of the times, users, which broke the locating pin on the K2D connector, connect it reversely. This causes the destruction of an electronic component (MAX238). Replacing it is sufficient to repair your K2D. Other rare causes can be broken cable, broken K2D connector or broken CCD.

Q: What is the difference between K2D and K6300?

The K2D is a standard analog CCD camera with a resolution of 510 TV lines. To operate a Khepera with a K2D, you need a rotating cable which is provided within the K2D set. It means that Khepera II with K2D cannot operate in autonomous mode: a PC with a framegrabber are needed.

The Vision 2D, or K6300, is a new product with a resolution of 160×120 color pixels and with on board processing. It consists in two Khepera turrets:

  • a MC68331 coprocessor turret dedicated to image processing,
  • a sensor turret based on a VVL 6300 chip.

This turret does not include an analog video output and consequently cannot fully replace a K2D

Q: What kind of external framegrabber is needed?

Any standard frame grabber can acquire K2D video output signal. In fact the requirement which is common to most of the framegrabber on the market are:

  • a BNC connector. However, a Cinch or RCA connector is OK if you have a BNC Cinch adapter.
  • support for standard analog video input. Standard means 1 V peak to peak / 75 ohm, however, you will often not find this information because this is the only analog video standard.
  • support NTSC or PAL video signal according to your K2D model.

If you are familiar with Windows and does not have any knowledge on image processing, I would recommend using a Matrox Meteor II with its image library but there are also many alternatives (Coreco, Imagenation,….) listed at the above URL:

http://www-2.cs.cmu.edu/afs/cs/project/cil/ftp/html/v-hardware.html

If you are familiar with Linux and have knowledge of image processing, I would recommend using any basic framegrabber card based on a BrookTree 848 chipset. At the following URL, you will find a list of commercialized carded:

http://linux.bytesex.org/v4l2/bttv.html

Q: How do I interface the K2D with MATLAB®?

You will need an external framegrabber, such as Matrox and interface it with MATLAB®. See Mathworks answers on framegrabber support.

Q: Can I transfer video signal with a Khepera Radio Turret?

The Khepera radio turret cannot transmit analog video signal, it is just a serial modem. Moreover, currently, there is no Khepera accessories that can acquire and process image to allow transmission of video frames over the Khepera radio turret. Hence, the K2D can only transmit video over its cable. FYI, this cable is equipped in standard with a rotating contact to avoid cable twists.

Q: Why my radio is so slow?

A: The radio transmission is much slower than a serial cable, for several reasons.

First, all data is sent in packets of 16 bytes, no matter what the size of the message, so your “N” command actually takes up 16 bytes of radio transmission, not one! The reply is 17 bytes, and so takes up two packets, or 32 bytes. Also don’t forget that there are hidden CR and LF characters that take up room too.

Second, there is a lot of transmission overhead that you don’t see which also takes up space (like a checksum) and because the radio is only half-duplex it needs to switch between sending and receiving modes which can slow things down a lot if you are trying to send and receive a lot of data at the same time.

Third, there is a certain random factor that depends on your environment: if you have lots of lost packets and the radio must resend them the effective throughput can drop dramatically. Take care to other wireless devices.

So actually the fact that the radio takes 5 times as long as the cable seems pretty reasonable to me. If everything is going well (ideal environment, all packets multiples of 16 bytes) you can expect to see throughput of around 9300bps, but that is a maximum.
K213 (Khepera)

Q: I cannot use the K213 for recognizing an object with the grey value return by the camera. Is this normal?

A: This is normal: the perceived grey value of an object depends on light condition. Hereafter is a more detailed explication. The K213 turret is mainly composed of 2 sensors, a specific hardware and the processor. The two sensors are the image and the light intensity sensors. The image sensor is a linear array of elements that charge themself under light exposure. If you keep them in the dark, they do not charge, if you place them in the light, they charge at a speed which depend on the light intensity. If they are too long exposed (can be some milliseconds), they saturate. Then to e-saturate them becomes long (can be one second). For this reason it is necessary to discharge them in a regular way (every X milliseconds), and at the same time it is possible to read the charge value. The problem is how fast to discharge them. The charging time for saturation can change from 2 ms under a lamp, to some seconds when there is no lamp… For this purpose there is this second sensor, which measure the light intensity and gives, as output, a scanning frequency which fits with the scanning needs of the image sensor. In between there is a specific hardware that makes the interface between these two sensors and the processor. This means that the two sensors scan the images and adapt to the light conditions by hardware and independently from the processor.

During this autonomous scanning activity, the pixel charge values are directed to an A/D converter which makes these values available to the processor in a digital 8 bit format. These values are stored in memory and send to the user when required using the protocol. All this correspond to a camera with an auto-iris. If you do a test, the problem is that the light conditions change and the scanning speed is modified. The processor cannot control this, all is in hardware.

Tweet
Share
Pin
Share
0 Shares