Playing with the MiniQ v2

I recently bought a DFRobot MiniQ v2 to evaluate as a possible pre-built robot to use in the robotics class I'm teaching.

Features

The MiniQ is small, but comes in a nice plastic case with a USB cable. (It also comes with another ribbon cable – I think it is used for add-ons, but not yet sure.) It has an intriguing mix of features:

• Built-in wheel encoders
• IR proximity sensors in front
• Left and right ambient light sensors
• An RGB LED (very bright!)
• Five line-following sensors underneath
• Three built-in pushbutton switches
• An HMC5883 compass module
• IR remote control unit (can be read through the IR proximity sensor)

There is no documentation in the box, but a Wiki and tutorial are available on the DFRobot web site, as well as other store sites that sell the robot.

Initial Tests

The tutorial is nicely thought out, but there appears to be some documentation problems, and the example programs are not great. A few first experiments:

Buzzer

Pretty straightforward piezoelectric buzzer. The examples work fine, but don't use the Tone library, which would be easier than the hand-rolled timing loops they use instead.

RGB LED

The example program worked fine. The LED is extremely bright. I may put a little tape over it to tone it down, unless there is a way to control the brightness in software.

Ambient Light Sensors

It took a little work to figure this out. The example program didn't work for me. It reads pin A5 and plays the buzzer at two different pitches depending on the value. However, the program almost always played the same pitch, and didn't seem to do anything as the light moved.

Playing around with the analog pins I noticed that A5 changed value when a flashlight was shined toward the left and right sensors. I didn't look at the schematic, but it looks like the two sensors are set up in a sort of voltage divider setup so that the analog value is about 500 when the light is equal, goes toward 1023 if light is stronger to the right, and toward zero if light is stronger to the left.

Based on the values I saw, I changed the example program by modifying the thresholds in the code: play one tone if the value is less than 100 (strong light from the left), and another tone if the value is greater than 800 (strong light from the right). This worked quite well when using a flashlight to excite the sensors. The old thresholds were 400 and 600, which didn't work well for me. The sensor value seems to fluctuate too widely when the light is equal to have that narrow an idle band.

Compass

The example program didn't include the library needed to read the compass. There are two HMC5883L libraries available. The Adafruit library was simpler to set up, so I used that to successfully read the compass. The noise is fairly high, +/- 10 degrees, so some sort of filtering, either low-pass or a Kalman filter, would be needed.

Motors and Wheel Encoders

The MiniQ uses micro-metal gear motors and 42mm wheels (maybe from Pololu?). In my opinion the robot is too fast. It would be better if the motors had a lower gear ratio. The encoders are optical, detecting the white plastic tabs on the inside of the wheels, 30 per wheel. Pololu sells a quadrature encoder for those wheels, but the MiniQ only has a single sensor per side. The sensors are fed to digital pins 0 and 1 (int.2 and int.3 on the Leonardo), making it easy to read encoder ticks by attaching interrupt handlers.

The motors are controlled by 4 pins, D5, D6, D7, and D12. Pins 7 and 12 control the motor directions, and pins 5 and 6 are used with PWM to control the speeds, using values from 0 to 255.

The drive mechanism and encoders doesn't work as well as I expected. There were two main problems:

1. When navigating in a small room, I found that speeds of 70 or lower were best. However, the motors may stall with speeds of 25 or less. So the granularity of speed changes in the usable range is higher than one would like.
2. The encoders seem to miss ticks occasionally. Because of the fairly narrow wheel separation, a missed tick means a heading error of almost 3 degrees. The robot seemed to miss ticks fairly regularly, making accurate navigation difficult. However, one could combine the encoder data with the compass, presumably, to increase the accuracy.

These are preliminary results, of course. The robot may have better accuracy than my initial impressions indicate.

IR Remote Control

Again, the documentation is sketchy, and there is no example program. However, the DFRobot Wiki suggests using the IRremote library. I was able to use this library to successfully decode signals from the remote control on the robot. There is no documentation on how the remote buttons are encoded into bit streams, however. I was able to use the IRrecvDemo example in the IRremote library to figure it out.

The remote control has 7 rows and 3 columns of buttons. All remote buttons send 24 bits. The first 8 are always 0xFD, if the signal was decoded correctly. The next 8 bits indicate the key, as follows, counting bits from left (0) to right (7):

Bits	Value
0–1	00=col 1, 10=col 2, 01=col 3
2–4	000=row 1, 100=row 2, 010=row 3, 110=row 4, 001=row 5, 101=row 6, 011=row 7
5–7	always 000

The last 8 bits are the same, but ones complemented. For example, power button is in row 1, column 1. It's signal value is 0xFD00FF.

(The row and column bit values seem strange until you realize that they are zero-relative row and column indices when read right-to-left.)

More Things to Try

I haven't yet had a chance to try out the obstacle avoidance (but the example program didn't work properly, spinning wildly at times, and driving too fast). Neither have I had a chance to try out the line sensors, since I have to get some poster board or butcher paper and lay down electrical tape. And I haven't yet figured out the pushbuttons; there is no example program, but the documentation says they are connected to A6, probably in a voltage divider setup. There is no documentation on the expected analog values for the different buttons, so that will mean some more trial-and-error.

First Impressions

The MiniQ is an inexpensive, pre-built robot, about $80 from DFRobot. It comes with several different sensors and a reasonable set of motors. I think the motors are geared too high, but that may be my bias. I've found it difficult to reliably control a robot in a normal room environment at more than about .2 m/s.

The documentation could be a lot better, but it is readable. The example programs, too, could be improved a lot. They have a lot of hard-coded values without explanation or use of symbolic constants. There are few comments or explanation of what the example program is supposed to do.

Overall I think the MiniQ is a reasonable way to try out several different types of sensors and software libraries without having to learn how to wire them up, and with relatively low cost. However, the example programs serve as only a start; considerable experimentation may be necessary to effectively use the robot. A beginner in robotics would likely need better examples or some hand-holding.