Driving DC motors with a PIC 16F88 (first draft…)

March 18, 2008 in Uncategorized | No comments

I’ve been struggle (I mean fighting against the whole universe’s darkness) for three month trying to drive DC motors with a PIC 16F88. I know it would be tough, but I didn’t know it would be so hard… Because this is about driving high currents (from ~500mA to 1A), and not just logic states as before. This SirBot ticket is a nice summary of what I’ve faced.

Of course, there’s a lot of people doing this, but it appears experience cannot be shared as easily as for other projects. I mean it seems that there’s a lot with the environment. Starting with the motor itself, which could definitively pertub the power supply, thus the PIC itself. Or the chip used to drive the DC motors: using L293D or its equivalent (but more powerful) SN754410 is not the same, and does not have the same impacts, particularly on the way the logic and the power supply are separated… And if anyhow you manage to get your motor rotating the way you want, as soon as you put it on load, you’ll discover the whole thing isn’t powerful enough…

Anyway, I couldn’t mention here all the problems I’ve faced. For now, I have a quite nice configuration (after burning/killing no more than 4 PIC), using SN754410 (far better than L293D, less noisy, …) driving my RC tank’s DC motors. Driving both motors makes SN754410 hot, about 85/90°C) which activates its thermal shutdown, thus turning off the whole… But that’s without heat sink DIP. If it persists, I’ll surely need to pick up my recently received LMD18200 or use the driving motor part of the RC tank’s original board… Whatever the result will be, for the time I’ve spent on it, I’ll make a new nice page on SirBot Modules, showing my “DC motor controller board”… And I hope you’ll mention my new BlueSMiRF bluetooth serial modem from SparkFun, which helped me a lot setting I2C communication both mainboard’s and DC motor controller board’s PIC. I need another entry… :)

Dissecting a RC tank

February 14, 2008 in Uncategorized | No comments
After dissecting a RC car, this is time for dissecting a RC tank… It’s been a while since I wanted to build a robot, a mobile robot, with tracks. Because tracks are cool, give nice mobility. But tracks are expensive. Very expensive. Tracks from lynxmotion cost about 220$, this price seems to be an average… So, using a rc tank could give a nice frame with tracks, ready to be used. Of course, quality cannot be the same (at least for the tank I have), but that could be an interesting proof of concept.RC tanks can be found easily on eBay. Prices vary a lot, but if you wait enough, you can get a nice one for very few. I got mine for 30€, shipping included (my first purchase on eBay). This a Leopard II A5 (but whatever…).

So what can be found ? Can this toy make a viable/usable frame ? Let’s have a look…

First of all, let’s have a look at those tracks. As in many tracked-vehicule, tracks are shorter on the bottom than on the top. This ensure minimal frictions while rotating (but less stability). Every wheels over the tracks have suspensions. While this seems cool, the poor quality may add a lots of “noise” while controlling the future rc tank based robot… Only the very last rear wheels drive the tracks. This is where motor are connected. All other wheels are just guide.
Batteries can be found on the reverse side. These are NiCd 1000mA / 9.6V. On the same side, five screws protect the tank from seeing its guts… Only one connector, which can be plugged/unplugged as needed, separate the base with tracks from the turret. Thats really good news, as hacking this tank won’t be too invasive.
Rear wheels connected to motors. With holes to drive the tracks. Tracks look very cheap… There’s no joint, it just looks like plastic ribbons (but seem adhesive). Tracks’ quality varies a lof according the tank (and its price…)…
Here’s the motors’ block… Opening the block shows two DC motors… As expected, both can be controlled separately.
The bottom frame is nice: lots of space, quite flat. The remaining board is for RC control. Probably to be removed. I’ve put my last mainboard on it, just to have an idea… I think this will be great :)

C

Experimenting back-emf motion feedback

February 7, 2008 in Uncategorized | No comments

It’s been weeks since I’ve tried to build a DC motor controller board. Particularly, this board must include a way to control and monitor the motor speed. This is an important step since it’ll be used as a dead-reckoning system on my future robot.

There are several ways to do this. Using code wheels (or encoder discs) with photoelectric or Hall effect detectors seems to be the easiest way, in a software point of view, but requires mechanical adaptations to include the code wheels. This would affect the design of the bot, and would be too invasive to include in a “hacked toy” (such as a tank rc, this is what I plan to do, the mechanical parts on the tank cannot be modified, and shouldn’t be). Anyway…

Another way to do this is measuring the back-emf feedback. This is well described here. Basically, voltage coming from the motor, while it’s turned off (not powered), must be measured using ADC. The value is proportional to the speed of the motor. Compared to the voltage applied, it’s possible to know if the motor is turning as expected or not (too fast, or more plausible, too slow). And possibly to adjust the applied voltage to correct the speed.

I found this nice page on back-emf using control feedback, with the same parts I use (16F88, L293D). This is what I’m currently trying to implement. Master Patrick also helped me a lof, with advices, suggestions and patience…

After several tries, first results are quite interresting. Here’s a series of screenshots from an experiment. There’s one DC motor. Its speed is increased at each step, using PWM. One step consists in activating the motor for 2 seconds, then shutdown the motor for 1 second. When PWM is turned off, an ADC measure is acquired and sent through serial link. This gives…

Lot’s of noise (more on this later), but we can clearly see how the motor is accelerating, step by step. As expected, while the PWM increase step is constant, acceleration is not linear.

Also note, during  the very steps, PWM is not high enough to make the motor rotates. There’s a voltage applied to it, but none generated…
  Zooming on a step show interesting things… First, each step looks the same:

  • an acceleration phase (not linear). PWM is turned on
  • a constant phase. The end of the phase is when PWM is turned off.
  • and a deceleration phase, quite linear. No more voltage is applied to the motor, but it produces voltage while “slowly” spinning down…
As said, there’s a lot of noise. Precisely, while measuring voltage produced by the motor, measures vary a lot. The motor produces a lots of electrical noise. Looking at the graphs clearly shows a main trend. Master Fenyo suggests to compute a sliding average in order to extract this trend. This is can be easily computed with:

An = k.An-1 + (1-k).an

where:

  • n is the current step,
  • An is the current average being computed
  • An-1 is the average at previous step
  • an is the new measure for current step
  • k is a coefficient used to balance the average with the new measure. 0 < k < 1

During this last experiment, I voluntarily slow down the motor several times. The green line is the sliding average, using k = 0.98 (the new measure has only 2% weight in the average). More readable, heh ?

Tablecloth scripting

February 6, 2008 in Uncategorized | No comments

“I plan to plot serial data from my PIC, in kind of real-time”. That’s what I’ve said to Master Fenyo. He said: “gimme a pen, you’re going to understand”. Here’s what he drew (click on pictures)…

(that’s about queuing theory, signal procressing, Fourier transform, sliding average and easy way to compute it, Poisson andNormal distribution, Markov process, PABX, alternative worlds in a probabilistic view, as in Sliders, dividing by 0.8 with a PIC,

Dissecting a RC car

February 1, 2008 in Uncategorized | No comments

As a robot builder, what can you expect to get from a rc car ? In great “Robot Builder’s Bonanza“ book, authors say: “You should consider hacking an existing toy to build you own robot platform. You’ll save a lot a time”. Building a robot mainframe from scratch is clearly time-consuming, particularly if you don’t have correct tools et materials. This being said, what can you really expect to get from a hacked toy ?

I’ve recently bought a rc car. Really basic, really “standard”, it cost approx. 30€. I wouldn’t consider the following as “hacking a toy” but as “dissecting a toy”. Here’s the list of pieces (from left/right, up/down):

  • a plastic frame, with a slot for Ni-Cad batteries,
  • a tri-state dc motor, used to turn left and right. This is just like a servo, but with only three positions: left, neutral and right,
  • a dc motor, with its gear reduction box (real crap),
  • several shafts,
  • a 6-pack Ni-Cad batteries,
  • four wheels,
  • a charger,
  • and four suspensions

That’s all… I plan to assemble some of this pieces to build a mobile robot.

Building the mainboard as a PCB

January 13, 2008 in Uncategorized | No comments

Last entry was about designing the mainboard, using Eagle. The result is a layout diagram, which will be the starting point of the next step: building the PCB.

The layout diagram is saved as a postscript file (print into file) to get 1:1 scaled  picture. It’s then lay down on a copper board, using adhesive.

Using something sharp, like a screw, each hole is marked. This is used to localize the holes once the paper is removed (…), and will later help to guide the drill bit.
Once done, the paper is removed. Using a special PCB pen, each hole is marked, according to the layout.

About the pen, it appears other pens also work, though I’ve tested these with details. Particularly, pens used to write on CD-ROM work nice. The thing is to spread a thin layer which will protect the copper from the ferric perchloride.
Start drawing the tracks. This step is very important and delicate. Tracks mustn’t be in contact, the drawing must be regular.
The reproduction of the layout is done. Double-check the tracks. Now it’s time to cut the board.
Use adhesive on both sides of the board. It’ll make the manipulation in the ferric perchloride bath easier.
Put the board into the ferric perchloride bath, and fix it on the sides using adhesive. Be careful, the ferric perchloride is very toxic and dangerous (acid). Use gloves, protect your eyes and your clothes.

Depending on how “new” is your bath and the temperature, the required time to “burn” the board may vary.
About 30min later, the copper starts to disappear. One this step reached, smoothly shake the board into the bath, until all the copper is gone (and the tracks still there…).
About 5 to 10 min later, the board is ready. Get off the bath and rinse with water. The tracks are black due to the pen. It’s time to clean it.
Polish the board to remove the pen layer, with a Dremel or the like. Do not damage the board with the drill. Also watch closely to the tracks to identify potential problems…
… like these ! One track has disappeared, another has several cuts on it. Fortunately, these can be fixed using some wires and an soldering iron.
Start drill the holes. This step is very delicate and could permanently damage your board: while drilling, the drill bit can slide and cut tracks. The best is to use a drill press. Depending on how you’ve marked the holes, things can be easy.

I prefer to drill first with a 0.6mm drill bit, then use a 0.8mm one. Some components required a bigger drill, like the power supply jack, trigger and 7805.
Then solder the components. Start with the straps, as they may be hardly reachable once every components are on the board.
Here’s the final result. Quite nice, even if things could be far better…

Designing the mainboard, using Eagle

January 12, 2008 in Uncategorized | No comments

Point-to-point wiring, using pre-drilled boards is too time-consuming, hard to reproduce and ugly… More, producing a picture like this one, representing the actual board, costs a lot (since no  software can provide this, AFAIK). It’s time to switch to a better environment.

 

So the idea is to produce PCB boards. But, before, I need to design the board. Eagle is a great software, available under Linux. It’s free for non-profit applications. It can be used to draw schematics, using a huge library of components. When done, Eagle is able to produce the PCB layout (using autorouting). Drawback is it’s quite tough to learn.Sparkfun has great tutorials which helps me a lot: drawing the schematics, building the PCB layout, and evencreating new parts.

 

First step is to draw the schematic. I’ve started from the previous mainboard and added modified it, according tothis ticket. Power supply is now provided by several connectors. They provides either +5V, either the unregulated power supply (used as input to 7805). The big 2×13 HE-10 connector is not splitted into two smaller 2×5 HE-10, one for PORTA, one for PORTB. +5V and ground are also available for convenience. Xtal quartz is now connected as a small board, so 16F88 can be configured to run with its internal oscillator (more, using different Xtal frequencies involves different caps, so Xtal and caps are dependent). Finally, a push button on MCLR can be used to reset the PIC without switching the power supply off (a little straight, but it works…).

The schematic is ready, it’s time to get the board. Eagle is able to build the board from this schematic… but it needs to be configured. The actual board will be built using special PCB pen and a copper board, so tracks and space between them shouldn’t be too narrow. After several tries, it appears 32mil is a good value (in “Design Rules”, “Clearance” tab and “Sizes” tab, “minimum width”). While configure “Autorouting”, I disabled the “top” layer, since this is a single side copper board. Autorouting the PCB gave 79% done, the last must be done manually. I define straps on the top side, with vias. I don’t if this is the best method in Eagle… Here the final result:

Once done, I print the layout in a postscript file (so scale is 1:1, whatever the resolution is), checking “Mirror” and “Upside down” options. The layout is ready to be reproduced on the copper side. Here’s a link to the postscript file.

 

Known bugs:

  • pin RA6 is not connected the PORTA HE-10 connector: (bottom right pin in the connector is a orphan)… Can’t really know why, since it’s connected in the schematic. Probably weird problems while connecting nets together. It’s not that important, since this pin is reserved for Xtal (when used), thus can’t be used in any daugther board.
  • the power supply polarity is inverted: ground is in center, + is around, while it’s often the invert. I’ve been fooled by the schematic of the power supply jack. Note a diode will prevent any polarity problems if not connected correctly. If the LED won’t light, the problem may come from this.
Once we have the PCB layout, it’s time to actually build the PCB. To be continued…

Wifi, Bluetooth and ZigBee

November 11, 2007 in Uncategorized | No comments

One the main problem with my bots (or the like…) is the way communications occur. I mean it can only use RS232 with a cable, and bots must stay closed to the PC from which they are actually controlled and monitored, and where data is stored. Basically, I need them to be wireless.

A first approach would use a PDA. The bot is connected to, with a RS232 cable (iPaq PDA have a serial connector). PDA then talks to the server using its builtin wifi or bluetooth and sends collected data. There’re even Linux distros which can be used on an iPaq, such as the familiar (works nice!). The problem is each time I need a bot to be wireless, I need an iPaq. And an iPaq is expensive (~ 120€ @ ebay). And big. And the one I have can’t have wifi or bluetooth.
Wifi ? Why can’t I use a Wifi board ? It’s way too expensive (~ 200€)… UART to wifi boards cost a lot, because from UART to Wifi, there’s a lot. Another problem is the battery life. If I want my bots to be wireless, they also need batteries. And wifi eats a lot of energy.
Recently, I’ve found some nice bluetooth OEM boards @ Lextronic. Cheap (~ 30€) and easy to use (on paper). Battery life is ok using bluetooth. Yeah, bluetooth seems to be the solution. When I’ve come to see those boards, I’ve realized how small they are. Way too small… That would be an advantage. But not for me, as I can’t even solder it (no pins, connectors are under the board). There’s another version: the OEM board is soldered on another board, with ready-to-use connectors. Even those connectors are too small, and this time this is twice the price (~ 65€).
So, what now ? Should I give up wireless robots ? When I’ve seen those bluetooth boards, the seller said: “Why don’t you use those tiny XBee boards ? Problem is you’ll have to have another boards connected to your PC, since none handles the ZigBee protocol“. And I said :”No way, I want a standard stuff”. Back to home, desperately giving up bluetooth, I’ve looked to those Xbee boards. ZigBee protocol seems to be a standard, but not well-known (Master Fenyo said: “It’s very usual, it’s also called the professional bluetooth”. Quite nice ! ZigBee is also known to be more reliable and uses less energy. Users report on forum those are very easy to use. And price is ok (~ 25€). Wikipedia shows an interesting comparison, showing why ZigBee is a good choice for embedded systems:

Comparison: Wifi, bluetooth, ZigBee
Protocol ZigBee Bluetooth Wifi
IEEE 802.15.4 802.15.1 802.11a/b/g
Memory needs 4-32 Kb 250 Kb + 1 Mb +
Autonomy (with battery) Years Days Hours
Number of nodes 65 000 + 7 32
Speed 250 Kb/s 1 Mb/s 11-54-108 Mb/s
Range 100m 10-100 m 300 m

ZigBee is my better choice. For now… The only problem is I need one on my PC. Next step is to check how this could be (very) easily done).

Sound sensor schematics

September 22, 2007 in Uncategorized | No comments

I put on SirBot website some quite detailed instruction to build a sound sensor, the one used to localize sound in space. This sensor uses an electret microphone, amplified by a LM386, a low voltage power amplifier. Using a microcontroller such as 16F88 and connecting this sensor to ADC pins, sounds can be converted, analyzed, even recorded. Finally, I’ve tried to make this sensor as small as possible.

Here’s the link to this SirBot’s module page.

 

Weather report from SirBot (DIY Nabaztag…)

August 18, 2007 in Uncategorized | No comments

I’ve recently been offered a Nabaztag rabbit. It’s able to do lots of little things such as reading RSS feeds, reporting the weather and air quality, … The problem is it’s not reliable: it sometimes crashes, repeats the same things over and over again. And most of all, it’s not very configurable except if you pay a subscription (but who might want to pay for something not working…). Anyway, it’s time for a “Do It Yourself” approach !

I’ve been play with PIC audio sampling, ADC and PWM for a while, and I have to say results are quite amazing ! Building a bot able to report the weather should be easy, provided:

  1. we’re able to produce a wav speech file from text (using text-to-speech, TTS)
  2. information from the Internet can be retreived and parsed
I’ve tested several TTS programs: espeak, festival, kttsd, but espeak is easy to use and produces a nice robotic voice :) It’s also able to put the result in a wav file.About information retrieval, Yahoo Weather offers a nice API to get a XML file (and no registration is needed) easy to parse (I actually used sed to get the weather and temperature from the XML file…).

The principle is the following:

The Jal program is simple: after configuring a PWM pin, it just receives data from the serial link (115200 bds) and sets the duty cycle with a 8 bits resolution. It can play PCM, 8 bit, mono 11025 Hz wav file (a wav file also contains information about the encoding. Those informations will also be sent, but that’s not a big deal :) ).
include sb_config
include sb_protocol
include sb_mainboard

-- Configure PWM
pragma target ccp1  rb0
pin_b0_direction = output
include pwm_hardware_1
PWM_Init_Resolution(20,true,false)

include sb_sound
pwm_on()

var byte char
forever loop
    if sb_serial_read(char)
    then
        PWM_Set_DutyCycle(char,0)
    end if
end loop
And… here’s the result:

(there might be problems with the video: voice might be too low, this a mov-to-flv conversion problem…).

If not clear enough, it says:
“”"
Hi ! This is the SirBot Project.Today, I’m gonna show you how to simulate those crappy Nabaztag stuff…
Here is the deal. I’m going to search information about the weather on the Internet.
Yahoo can help us. It has a great API to retrieve information about the weather.
So, let’s go !

I’ve been configured to check the weather on Paris.
So, here’s the weather report on Paris, France:

The weather is “Partly Cloudy”.
Temperature is “19″.
“”"

« Older entries § Newer entries »