This is a copy of the "spidy" robot that was published on LMR last Noverber by myblack60impala.

  Sparkfun ProMini
  2 DFRobot Spiders
  HG7881 Motor Driver
  Radio Shack 4 AAA case with switch
  4 AAA batteries

In total the project cost about $30 US and took about 4 hours to build and program for a simple forward/reverse motion.

This is rev 2 of the electronics. First module used 3 AAA batteries and a Sparkfun Pro Arduino. There was insufficient power to navigate on anything but a hard surface. Also the board and battery did not fit cleanly.

This time it is quite peppy but there is insufficent 5V power available to run the Sharp IR distance sensor. Double sided tape mounts the cpu board to the battery slide on case. The lack of power pins on the pro mini also required me to splice the HG7881 power with the CPU & battery cable. Used liquid tape (black & red) which nicely covers the solder joints.

Rev 3 will be a home brew PIC24 based board with 250ma on both 3.3V & 5V. There is a 2 week lead time for boards thru Oshpark so I will hopefully publish an update.

Thanks to other LMR's I have another toy.

The PIC24 arrived and is driving the motors. Screwup on one of the SPI lines to the NRF24L01 but hope to add a jumper wire to continue the debug effort. This CPU board has 4 AAA battery clips on the bottom. Not sure they are woth the effort vs independent battery case.

Completely stuck on how to go in a straight line. Five schemes have been discussed on the Shout Box.
   1. Forget the motor feedback and use a digital compass.
   2. Add optical wheel encoders.
   3. Add magnetic hall effect sensors
   4. Try to detect motor commutator noise.
   5. Add accelerameters or MPU to detect steps.

I am leaning towards number 5. Monitor the Z axis for a period of time (25 msec) and collect approx 500 samples with a low pass filter keyed to the expected frequency. Then use a FFT to get the frequency. Putting the sensor outboard the legs should help minimize the vibrations for the opposite leg assembly. The PIC24 is a 16 bit CPU running at 40MHz so I expect to be able to do an integer FFT.

Options 2 & three are simpler but there is not much room for discs as the unit is currently built. Printing some plastic parts may open up the interior.

Will post pictures later this week when I get to a reasonable internet. Comments welcome!

Update 9/30/2015

The blank boards have been here a couple of months now. Finally got around to putting down some components and started on the software. The major change was going from 4 AAA batteries to 5 and dedicated voltage regulators for the motors.

A problem on the board is two of the battery clips come too close to some I/O header pins on the bottom side. Hacked by filing the pins down and adding a piece of insulating tape. Probably would have been easier, faster and neater to just file the clips. Revised the foot print for the battery clip to clearly show the interference. I usually take me three revisions to get it correct so this project is on schedule.

The dedicated I/O headers for the I2C mpu6050 and SPI nRF24L01 are nice and the power looks clean. I did not know if the brushed motors (very inexpensive) would interfere with the radio but testings within 5 meters range has he good. I have a problems with the mpu6050. The I2C message gets hung and I have not found the magic code to unlock.

The purpose of using the mpu6050 was to try and detect footsteps by looking for changes in acceleration. So far that has eluded me. Have been taking samples every 10msec and uploading to host via radio for analysis. Going to change to 1 msec today. I suspect I will add a traditional quadrature encoder on the motors.


This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/spider


AWESOME!  (though its worth noting, I copied the other DFspiders on LMR :slight_smile:

Fear us Bob builders! …the Spiders are taking over!  :smiley:


I should add that it took me 20 minutes to cut the X-bracket that connects the two halves to the center gear case. 19 min, 58 sec thinking, 2 sec of snip and hope this is right!


I just tried to snap it in place and it didn’t go, so I was like - “Thats what they were talking about!”  :smiley:


And now for something completely different -

I was thinking about combining 3 of these kits to make a weird looking wide spider with 24 legs. I have no reason why, other than it has not been done before. Then parallel the outer leg motors and vary the PWM for the inners to skid steer in a “matched step” kind of way. It would be interesting with all the wiggly legs going crazy.


I have to imagine

driving this bot straight will be no easier than driving a treaded bot straight is. Slippage will drive you bonkers. In other words I don’t see a place where you will win any dead reckoning competitions with this platform. :smiley:


Bird’s comment is very right generally speaking. But me, I would simply put a white dot on a leg and a IR sensor to read when the dot passes, or beam breaks the sensor. Right or wrong, that is how I would do it. Slipping can always be a problem. But I don’t think it would be a major factor at slow speed turns since these being legs, they get more traction than wheels. On a tile floor no movement device will truly get traction. So I would just do it as simple/cheap as possible and move on to the next feature you would like to implement. My 2 ¢.



I haven’t thought about slippage yet. The differences in the motor responses to the same PWM value is current problem.


IR sensor

I am not following your white dot and IR sensor scheme. Pleaase elaborate.


You can get IR sensors in different physical shapes, or in the raw form of leds. Basically all form factors of these sensors could be made to work to track your step length. You just need a white or black dot on the leg to reflect or block the IR light when the leg passes by the sensor.

If I were to put this kind of feedback on my spiderbot I would use the Photogate style IR sensor (or leds mounted in this way) and mount one sensor per side of the spider so that as a leg moves in its full range of motion it beam breaks the sensor (with a black dot on the leg in this case) which in turn allows you to know that the robot moved one step length. Thus providing you feedback on the robot moving.

Bird’s comment comes into play as traction can limit this kind of feedback from leg slip. But on the other side of this argument. This kind of feedback is super easy to implement. So its worth the potential traction issue when you can compensate by doing a code reset to effectively start your leg tracking over in code. Or better yet just turn at a slower speed than you walk forward. Because its mostly the turns that limit this kind of feedbacks accuracy.

Hopefully that explanation makes sense.  :smiley:

Hi, I’m wondering, because



I’m wondering, because I have a similar robot using the same legs, how easily does this one move? Mine walks with alot of difficulty and I’m wondering if this is because of weight (both 4x AA and 4x AAA have been tried) or because of how I drive the motors.
With 4xAAA batteries it will be quite heavy, so I’m wondering how you drive the (standard?) motors to achieve a brisk walk.
What’s the weight of the bot and voltage regime applied to the motors? 4xAAA(1.25V) in one go or PWM or…?


kind regards,



I using 4 AA on mine for both the controller and motors.

I am using 4 AAA batteries which give about 5.3V total when fully charged. The battery is connected to the h-bridge and a dual 3.3V/5V regulator. My current h-bridge is a Si9986 and is much peppier than with the previous (I forget which) one. With batteries it weighs 9.7oz or 275 grams.

Nice little spider

Hi ggallant,

Nice little spider robot you have there. Good job !

Do you have a video showing the robot in motion ?

4 x AAA batteries should be enough to power the Sharp IR (for the GP2Y0A21YK0F, its operating supply voltage : 4.5V to 5.5V with 40mA average current consumption)

I like myblack60impala’s idea of adding some optical sensors to detect the leg’s motion and have some sort of feedback. Hopefully, the legs will not be too fast to be detected by the sensors.

Plan A

I was fascinated by Klanns mechanical spider the first time I saw it:


IMHO, counting steps will prove futile, there will be enough drift in the mechanism to cause grief. And enough noise in the counting to add to that.

I would use an MPU9051 and use one of the combined compass routines to get real time readings and steer the course. Could be an interesting way to steer it, ie steer 2 points to larboard matey!

Sharp IR

No video yet. I am somehow killing the I2C bus. Don’t know if it is electrical or software. Taking forever to debug. Works ok if I sample the mpu6050 every 100msec and upload the data to a host via nRF24L01 radio. If switch to collecting and storing N data points at 1 msec sample rate and the uploading to the host if kill the I2C bus.

Previous revision used 4 AAA batteries. Good for 3.3V regulators but marginal for 5.0. Fully charged AAA’s are about 1.35V an you need some headroom for loss in the regulator. Finding the 5th battery usefull.

I plan to add either IR or Sonar sensors once the motion feedback has proved a success or failure. My experience with the Sharp IR is they consume about 30ma on average but about 220ma for about 10% of the duty cycle. 

I’m current mentally stuck on MPU sensor. The scheme for optical sensing leg movement sounds much more reliable. Also adding a encoder to the motor or gearbox output seems better. I have collected a few samples that are encouraging.