Older blog entries for shimniok (starting at number 58)

TOTT Bot, OpenMV, RoverPower, and more

I'm still working on TOTT Bot, the robot that takes out the trash. I've built a chassis with Actobotics parts, but want to rework it before I post more.

The more I think about it, the less I like the idea of grabbing and tilting or even lifting the trash can. I'd kind of like to explore turning my trash cans into trailers that the robot can hook up to and drag to the curb.

I'm also working with the creator of OpenMV to bring them to market as it were. We'd both love to see a really low cost machine vision module in the hands of hobbyists. One that is capable of 25fps face detection, real time color blob detection, USB support and more. Look for more updates over the next several weeks.

That's not all...

I've developed a compact RoverPower module that combines a 5V supply with battery voltage and current monitoring that will replace my
AttoPilot and Pololu 3.5A step down switching power supply.

Don't get me wrong, I love the Pololu supply. I have three. I recommend them all the time. But for my Rover I wanted to consolidate. So why is RoverPower a better configuration?
  • One compact board instead of two ungainly ones
  • It has mounting holes
  • I2C enabled because we never have enough ADC ports
  • 5V 1.5A supply with multiple output ports
  • User configured oversampling for low noise high resolution
  • Small at about 0.96" x 1.2"
  • Use any connector, not just Deans
  • Should handle 4S and 60A
  • This will cost notably less than AttoPilot ($19.95) and do more
A revision to RoverMux is in the works. The new version is simpler, just plug in and go. The BEC jumper (see above) is history. Revision 0.4 also fixes a missing AVRISP trace.

I'm excited to review the AVR Dragon debugger/programmer soon. I've been borrowing an exorbitantly priced JTAG ICE MkII for a few years. The Dragon is much cheaper but it looks like it can do a lot: HV programming, debugging, flashing in-system or out, and more. Can't wait to use it.

I'm also really eager to start working with the Freescale Freedom KL46Z. It's mbed compatible and has some neat peripherals: a microscopic 4-digit LCD display, accelerometer, magnetometer, capacitive touch slider, Arduino form factor headers, 48MHz Cortex M0+, 32K RAM, 256K Flash, lots of SPI, I2C, I2S, UART, PWM, ADC, and DAC peripherals.

I've become intrigued by Freescale ARM processors of late; they seem to pack a whollop with great price-for-performance ratios, really fast ADCs and more. And the Freedom boards seem a bit more usable than the daunting double-row-of-pins you get with a Discovery board.

I'm also working on a large display day/time clock for my mom. I've run into some snags with the enclosure but as soon as I get that wrapped I'll post up the build.

Syndicated 2014-01-30 17:00:00 (Updated 2014-01-30 17:00:04) from Michael Shimniok

28 Jan 2014 (updated 4 Feb 2014 at 00:14 UTC) »

Debugging mbed, progress so far

I've been working on the code for Data Bus, my autonomous rover, in particular inserting FreeRTOS into the mix. Doing so made hardware debugging a necessity.

I've made a little progress with that and thought I'd share. Ideally I'd like to integrate debugging with Eclipse but have had to settle for command line for now.

You may recall I'm using the LPC1768 mbed. The mbed project recently implemented CMSIS-DAP which is a standardized interface to the ARM core's debugging hardware.

One can use a fork of OpenOCD that speaks CMSIS-DAP (until they merge those changes in). I used this fork. OpenOCD implements a gdb server to which your gdb command line client can connect.

I also found it immensely helpful to use pyOCD which takes care of launching the OpenOCD gdbserver for you. Follow the readme instructions on the pyOCD repo. You'll need python, of course, libusb (apt-get install python libusb for distros using APT), and pyUSB.

Apparently you can also write python scripts with pyOCD to interact with CMSIS-DAP (details here).

I haven't gotten Eclipse integration sorted out just yet...

Some of the question marks pertain to how Eclipse communicates with the gdb server, what commands it issues. I haven't dug in beyond "it doesn't work in Eclipse" to find out what is going wrong, let alone what the cause is. I'm sure I'll figure it out eventually. Probably someone else already has and I just need to find their blog post. :) (EDIT: Like this one submitted by Matthew)

Alternatively my plans to migrate to LPCXpresso means I could just use CodeRed and not worry about all this. :)  But that limits me to very few ARM MCUs. There's a lot of popularity growing around STM32 and Kinetis ARM MCUs lately. ARM is destined to become the primary hobbyist MCU of choice in the next few years and we need full, open source toolchains and IDE integration to get there.

Syndicated 2014-01-28 17:00:00 (Updated 2014-02-03 23:34:16) from Michael Shimniok

24 Jan 2014 (updated 22 Feb 2014 at 05:16 UTC) »

Diagnosing a Broken Oscilloscope

Analog oscilloscopes practically diagnose themselves. Without ever taking off the cover, here's how I tracked down a new problem on my primary oscilloscope.

I bought my BK Precision 1590A* quad-trace oscilloscope a few years ago because I liked the new-fangled blinky lights and pushbuttons, knowing full well I'd regret it some day.

It quickly became my primary oscilloscope due to small size and big features and soon it was my only scope as I sold off the others.

Then "some day" became today. The fancy blinky-lights and buttons on the CPU-controlled 1590A are spazzing. Some buttons don't work and those that do activate totally unrelated functions. I'm left wishing for mechanical switches. Drat.

Where do we start? I'll tell you...
A few years ago I found this wonderful Tektronix manual on (analog) oscilloscope diagnostics appropriately titled Troubleshooting Your Oscilloscope [pdf].

Blocks and Their Functions

How does an Oscilloscope work? By plotting voltages versus time. Oscilloscopes are designed and built in blocks of circuits. If you know what the blocks are and what they do, you can identify which block is causing problems. While other sites (like this one) provide more detail, here's a quick overview of the blocks and their functions.

Referenced here from Doctronics
for educational purposes

Vertical Pre-Amp 

Oscilloscopes draw a voltage waveform on a cathode ray tube (CRT) by sweeping an electron beam in the X and Y directions. The vertical pre-amplifier takes the voltage of the signal and scales it. When you manipulate the volts-per-division knob, the vertical position knob, the mode (CH1, CH2, DUAL, ADD), you're controlling the vertical pre-amp.

Vertical Amplifier

The vertical output amplifier converts the output of the vertical pre-amp signal into a high voltage that vertically deflects the electron beam in the CRT.

Sweep Generator

The beam also sweeps left to right at selected intervals, thanks to the sweep generator block. When you change the time/division knob or the horizontal position, you are controlling the sweep generator. It generates a sawtooth sort of waveform that's amplified to hundreds of volts by the horizontal amplifier to deflect the CRT electron beam left to right.

Blanking Circuit

When the sweep reaches the maximum (the beam reaches the far right), a blanking circuit turns off the beam until the sweep waveform returns to zero.

Horizontal Amplifier

The output of the sweep generator is fed into the horizontal amplifier to generate a high enough voltage to deflect the electron beam horizontally.


To make sure you see the same shape every time the scope sweeps the electron beam, a trigger block makes the sweep generator wait at zero until the input signal reaches the trigger voltage level you've set. The blanking circuit is then disabled and the beam begins tracing at the same input voltage as last time. In other words, the trigger circuit synchronizes the sweep generator to the waveform.

Power Supply

As with many electronics, if the power supply goes bad, all sorts of problems occur. That's what was wrong with my HP204, for example. And an analog CRT oscilloscope has several power supplies: logic level 5V supply, medium voltage supplies for pre-amps, and high voltage supplies for the CRT.


After messing with the malfunctioning scope haphazardly, scratching my head, and being overwhelmed by the circuit diagram (these are steps -2, -1, and 0, respectively), my "first" step was to systematically take detailed notes on the oscilloscope's symptoms and behavior, what was working, and what wasn't working. Basically you use the front panel controls to determine with what major block the problem lies.

First Step: Behavior

I said the scope was acting weird. Here's what it's doing.
  • Pressing MODE ADD should display a single waveform that is the sum of CH1 and CH2 voltages. Instead it switches to CH1 mode. Um... ok. That's strange.
  • Pressing TRIGGER SINGLE is supposed to activate single trigger mode. Instead it switches on X-Y where the CH1 input deflects the beam vertically and CH2 deflects it horizontally. I wasn't even pressing a button on the HORIZ DISPLAY area.
  • Pressing HORIZ DISPLAY A should switch to the A time base. Instead it activates MODE QUAD, displaying all four channels on the screen. I wasn't even trying to change the MODE. HORIZ DISPLAY has nothing to do with MODE.
It's like I press one key but the scope thinks I've pressed an entirely different one. Hmmm.

Now why would that be? (You probably already figured it out, didn't you?)

Second Step: What Isn't The Problem

I said that oscilloscopes sort of diagnose themselves. Without going into excruciating detail, here's how I can tell by looking at the waveform display which block(s) are affected. If you want the detail, take a look at the pdf I linked to above. This is just a rough outline to give you the flavor of it.

A malfunction in the vertical pre-amp or amplifier could manifest as non-linear or completely non-existent vertical deflection, or a beam that is deflected too high or low, despite adjustment. I had a Protek P3502 with this deflection problem due to a cooked power resistor in the vertical amp. The 1590A shows no such symptoms.

A problem with the horizontal pre-amp or amplifier could result in a non-existent sweep with the beam stuck (a dot or vertical line on the screen), as was the case on my Hitachi V1050F, or a non-linear sweep as recently started happening with my Heathkit IO-12. You may also see a beam that is deflected to the far right or left despite adjustment.

A trigger problem might result in a mess of waveforms overlaid instead of a single crisp shape while a Z-axis amplifier  problem would affect the intensity of the beam. In fact the beam may not appear at all. A power supply problem would probably affect multiple areas.

My 1590A has none of these issues. It works just fine horizontally and vertically. I simply can't control the operating configuration of the scope. I never use ADD or SINGLE so those aren't an issue. But I almost always use the A timebase, so it's a pain to have it in the other horizontal display modes.

Eliminating the other blocks I'm left with one, unique to newer analog scopes like this one: the microcontroller. In truth, I kind of had a feeling there was something logic-y about this problem. I just wasn't quite sure what was going on. So I had to look at a service manual for more information.

Third Step: Get Schematic and/or Service Manual

Service manuals for many oscilloscopes can be found online--for free. Sure, you can pay money for a manual but do your searching first. And maybe post on a forum or two.

What you're really looking for is the schematic diagrams. You might find block diagrams, schematics for each board, and maybe a schematic showing connections between all the boards. If you're lucky you'll also find part numbers and descriptions for each of the many components on the boards.

Board level connection diagram, BK 1590A
With the manual in front of me, I started by looking at the block schematic to get a sense of what the malfunctioning switches are connected to and how things work at a high level. I traced connectors from module to module and found the panel switches and their LEDs connect to a CH3/4 Amp board and to the CPU Unit. I didn't quite understand how the amplifier board was involved until looking at the Schematic.
The right half of the CH3/4 AMP routes signals
Half of the board is used to pass the switch and LED signals to/from other modules. With a better sense of all the boards involved, I started tracing individual switch pins on the schematic. Each connector is numbered and so are each of the connectors' pins, making it easy but tedious to track down where all these signals go.

What I found was that the buttons are arranged in a 4x4 keyboard matrix. Upon documenting the switch and microcontroller pin connections in a table, the pattern emerged. The table below shows the matrix lines K0-K3 and P0-P3 connected to each button. The buttons misbehaving are highlighted in red.

K0 K1 K2 K3

As you can see, every button attached to the P0 and P3 lines are faulty in some fashion. Why? I don't know yet. It could be a faulty microcontroller. It could be a cold solder joint somewhere. But at least I know exactly what's wrong.

Fourth Step: Opening The Case

It was finally time to open the case and perform further diagnosis. With the case open I was faced with the extremely daunting task of extracting the CPU board from beneath a plate of copper shielding material with dozens of grounding straps soldered to it. Ugh.

The MCU pins are seeing the buttons being pressed.
Once that was done, I attached my beloved Saleae Logic to watch signals on the MCU pins. What I discovered was that the signals from the switches are, in fact, reaching the MCU pins. That eliminates a slew of possible issues and points the finger of blame somewhere inside the ancient chip.

So, now what? Repair. I am probably going to hack the scope, replace the MCU with an AVR and call it good. But that part will have to wait for a future article.

Alternatively, I may let the scope sit awhile. I bought a 100MHz Hewlett Packard 1740A dual channel scope to stand in.

If you found this useful and think others might too, could you take a second and share it? Thanks!

* Incidentally, based on markings inside, the scope appears to be manufactured by Kenwood Trio. Or at least contains parts from that company.

Syndicated 2014-01-23 18:00:00 (Updated 2014-02-22 05:05:08) from Michael Shimniok

Two RFM12B Arduino Clones

Funky V2, picture from Martin's Corner on the Web
The Funky v2 is an Arduino Leonardo clone with RFM12B radio module, much like the JeeNode I've posted about before, but considerably smaller at 22mm x 22.8mm.

It's meant for low power, battery operated, remote sensing. It also has a USB interface. I've never tried one but perhaps one day. I'm still trying to find the time to finish my mailbox sensor project.

Unfortunately, neither Funky is in stock as of this writing and I'm not sure that availability is great as Martin makes these by hand with extra PCBs from his projects.

MegaRF modules from Heye's Shop

Similarly, the megaRF on tindie.com is currently out of stock. It's based on an ATmega168 and RFM12B. The module is made by Heye out of Germany.

I'm curious, dear reader, do you want, need, or use wireless sensor modules?

Syndicated 2014-01-21 18:00:00 from Michael Shimniok

Check this out: LPC800-MAX

Have you heard of the LPC800-MAX? Arduino shield-compatible, mbed-enabled, and LPCXpresso pin-compatible one one board. Costs about US$20.

LPC800-MAX image from mbed.org
Perhaps you saw one of the reviews, maybe the, erm, editorial from Olimex? What are your thoughts on this board? Here's my summary...

It's not hard to see the reason for the vitriol from Olimex. The use of external ADC and I/O expansion ICs is a baffling kludge--if the goal was to build an Arduino competitor. Why not use a much faster LPC with more memory and flash and with all the requisite pins and peripherals? I suspect the board exists to sell the LPC812 as an 8-bit killer.

The mbed support in particular makes it tempting to get one since I am quite familiar and happy with mbed. I don't know if the expansion ICs operate transparently but if not it'd be a bit cumbersome to use. So, would you buy one? Is NXP nuts?

Syndicated 2014-01-16 17:00:00 (Updated 2014-01-16 17:00:01) from Michael Shimniok

13 Jan 2014 (updated 13 Jan 2014 at 19:12 UTC) »

AVC Planning with SHARC!

SHARC (our local robot club) had an awesome AVC planning meeting Sunday at Deep Space in Parker. Big thanks to Sparkfun for talk and pizza and RoboRealm for paying our meeting fees!

AVC? The annual Sparkfun Autonomous Vehicle Competition. Air and Ground vehicles compete in a fully autonomous race, drawing competitors from around the globe and thousands of spectators.

Sparkfun presented on the AVC, Scott Harris (2 time AVC winner) and I did an impromptu talk about our robots, and everyone was jazzed about the AVC.

Then SHARC founder George announced our top secret AVC entry. It's going to be huge! We have a number of very smart folks signed up to help. But, it's a little too early to reveal the secret. If all goes well I'll do so later.

If you want to find out what we're planning, subscribe to this blog's RSS feed.

Meanwhile I'm continuing to work on my own AVC entry, Data Bus, for 2014. 

Some of the SHARC attendees

Syndicated 2014-01-13 18:00:00 (Updated 2014-01-13 18:44:59) from Michael Shimniok

Check this out: DIP ARM with BASIC

Did you know there was an ARM in DIP form factor? The LPC1114. Well, not only that but you can program it in BASIC. Coridium is selling a 50MHz LPC1114 in DIP form factor for a measly $10 for just the MCU or $42 for the eval kit shown below. My very slow BASIC Stamp II cost about $50 ten years ago.

The ARM BASIC was released awhile ago, but I don't think it got the press it deserves. I played with mine a little but still haven't had a chance to do a project and write-up.

Programming it reminds me of the Stamp's BASIC. One neat feature the Stamp didn't have: you can access any native MCU register so you have quite a lot of control over the device's peripherals.

Syndicated 2014-01-02 17:00:00 from Michael Shimniok

Check this out: Muscle wire

Have you heard of muscle wire?

It contracts when you pass current through it, heating it up, and returns to its original length when it cools.

It's made of shape memory alloy called Nitinol which undergoes a "reversible solid-state phase transformation known as a martensitic transformation" [Source: Wikipedia].

Have you used it? Post up your projects in the comments.

Syndicated 2013-12-18 17:00:00 from Michael Shimniok

Robotic Christmas, Autonomous Systems Lab

Here's the 2013 Robotic Christmas video from the Autonomous Systems Lab. Enjoy!

Syndicated 2013-12-17 21:06:00 (Updated 2013-12-17 21:07:21) from Michael Shimniok

10 Dec 2013 (updated 19 Feb 2014 at 01:13 UTC) »

Trash Robot Design, Part 2

Requirements | Design 1 | Design 2 | Chassis ]

Previously we looked at an option of lifting the trash can and driving it down the driveway to the curb. This time around let's look at the other option of grabbing the can's handle and wheeling it to its destination.

Grab the handle and wheel the cans to the curb

The robot can either tilt the can and roll it like I do or drag it flat. Again, one robot. Stock (or slightly modified) can. Less force is required to tilt the can than lift it as you might intuitively guess.

Probably a good idea to do some preliminary calculations on this tilty thing. The force required to tilt the 25kg can around its wheel axles measures 45-50N.

About 45-50N is required to tilt the can at its handle.
If you use some kind of arm to do this tilting, how much torque is needed?
If you use an arm that reaches from the wheel axle to the handle, the distance is approximately 0.8382m from the ground less the 0.0762m wheel radius, or 0.762m, so about 38N-m. If you instead use a shorter arm, less torque will be required of the motor, but you won't be able to tilt the can as far.

Minor problem

While tilting the can, you need to counteract the force required to tilt it. If the chassis has trailing wheels as pictured above, they will tilt up if the force f2 exceeds the gravitational force at the trailing wheels. So to keep the robot from tilting, put a mass over the trailing wheels at least f2/9.81.

There's leverage at play here. If the length of the robot equals the height to the pivot point of the arm, then f= f. If the length is shorter as pictured, then f> f, by a factor equal to the ratio of these two distances, otherwise f< f, by the same factor.

A longer arm means less leverage on the trailing wheels by the arm pivot point. But the motor torque on the arm will have to increase to apply the same force. A bigger motor or lower gearing, meaning lower speed, will be required.

Another option, the robot could drive the motors backwards toward the can while tilting to counteract the force with the main drive motors' torque.

Still another option, put the upright and arm more toward the robot's middle, reducing leverage of the pivot point.

I'm sure you figured out five minutes ago that the simple solution is to put the trailing wheels on the other side, but then one side of your chassis will have to be open which means the chassis will be less rigid unless you add additional reinforcement. Seems like a reasonable solution.

How do you turn?

One more thing to think about when wheeling instead of lifting. How do you turn the robot when you're clamped onto a trash can?

Let's assume the robot will have differential drive because that will provide the best maneuverability in tight quarters the robot is likely to see. To turn the robot, one wheel goes forward, the other in reverse. Each exert an equal force, fw. The total turning force at the robot's track width is 2fw.

The torque exerted by both wheels is 2fwr. Now if you have a trash can with its own wheels sitting on the ground and those wheels aren't coaxial with those of the robot, you have some problems. Here's why (even though you probably know this intuitively).

The drive wheels will exert a force at the trash can wheel. That force will be perpendicular to a line drawn from the can's wheel to the robot's center. How much is the force?

Imagine a there's a virtual arm with a force at a distance r2 shown below. To find the force, take the torque and divide by the arm's distance.

So, for one thing, the force is smaller than it is at the drive wheels. More importantly, the force is trying to move the trash can's wheels mostly sideways. Yeah. Good luck with that.

So either we put our drive wheels next to the can's or we have to have a pivot point where the robot grabs the can.

Pivot Point

With a pivot point we're now able to exert a torque on the trash can. The force at the pivot is still 2fw. The torque exerted on the can is proportional to the radius of this pseudo-trailer's tonque, 2fwrt. The force exerted at the can's wheels is the torque divided by the wheel radius of the can, rc.

If we have a trailer, and we have trailing wheels behind the robot to deal with the lifting torque of tilting the can, that means we have to make the chassis wide enough to let the trash can turn. Something else to think about.

But hey, at least we have a few major design options to try and choose from:

  • lift the can and drive, 
  • drag the can on a pivot, or
  • drag the can with wheels coaxially located. 

There's a lot more design to work out just on the physical side let alone software and electronics. We'll get to all that. But for now, I'd like to start prototyping the chassis. I like to build the electronics once I have some idea of what the chassis is going to look like.

Next: Prototyping the Chassis

Syndicated 2013-12-10 17:00:00 (Updated 2014-02-19 01:04:08) from Michael Shimniok

49 older entries...

Share this page