AltoEdge Infinity USB Foot Pedal Dates Back Before Windows 7

This SGVHAK teardown project came courtesy of an electronics waste bin. A nondescript box with a USB cable, it has three moving parts on top of a heavy base. The center piece takes up majority of width, and two far smaller pieces sitting on either side. Each piece can be pressed down and we can feel a tactile click of a switch. It has a respectable heft and doesn’t look damaged or even worn. It feels rather beefy and unlikely to physically break.

Infinity Foot Pedal IN-USB-2

A label on the bottom of the device lets us know it is version 14 of the Infinity IN-USB-2 foot pedal. Which explains its mass and durability: this box was designed to sit under a desk and be stepped on. A box sitting out of sight explained its raised side pedals allowing its user to find them by feel.

Infinity Foot Pedal IN-USB-2 v14 label

A few screws on the bottom held a plate in place, easily removed. We see a few springs for the pedals, and two pieces of metal that gave the device its heft.

Infinity Foot Pedal IN-USB-2 bottom panel removed

There were a few visible plastic clips holding individual pedals in place, but they were only the first line of defense – unclipping them allowed individual pedal to move a little further but did not release them. There were also a few hinge pins that could be removed, but again it allowed additional movement but did not release.

The two shiny metal weights were held by tenacious stretchy glue. We could pry them up far enough to see they weren’t obviously hiding screws, but we were wary to apply addition force as it threatened to break apart the plastic housing.

Without an obvious way forward for nondestructive disassembly, we decided to pause and reassemble the pedal to see if it can be useful intact before we risk destroying it. My computer was running Ubuntu at the time, which gave us a starting point with the dmesg tool to see what kind of greeting it has to say to my computer.

[ 459.086214] usb 1-4.4.3: new low-speed USB device number 17 using xhci_hcd
[ 459.192673] usb 1-4.4.3: New USB device found, idVendor=05f3, idProduct=00ff
[ 459.192679] usb 1-4.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 459.192683] usb 1-4.4.3: Product: VEC USB Footpedal
[ 459.192687] usb 1-4.4.3: Manufacturer: VEC
[ 459.196360] input: VEC VEC USB Footpedal as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.4/1-4.4.3/1-4.4.3:1.0/0003:05F3:00FF.0012/input/input28
[ 459.196980] hid-generic 0003:05F3:00FF.0012: input,hiddev1,hidraw9: USB HID v1.00 Device [VEC VEC USB Footpedal] on usb-0000:00:14.0-4.4.3/input0

So far everything looks in line with the manufacturer’s name we found earlier. It also tells us the device conforms to USB HID (Universal Serial Bus Human Interface Device) specification. The final line also hinted us to a newly visible device under the path/dev/hidraw9.

$ ls -l /dev/hidraw9
crw------- 1 root root 240, 9 Mar 17 13:32 /dev/hidraw9

This path is owned by root, so further experimentation requires taking ownership of that path to see what we can do with it.

$ sudo chown $USER /dev/hidraw9

Now we can try treating it as a file with the cat command. Every time we press or release a pedal we get some kind of visual feedback but we don’t understand it.

cat dev hidraw9

We then tried treating it as a serial port using minicom but that didn’t get us much further. It vaguely resembles the garbage that might occur if a baud rate setting is incorrect, but changing baud rate in minicom didn’t do anything. Probably because it’s not a serial port!

Since the device was classified as a USB HID v1.00 Device, the next thought was to try communicating with it via some sort of HID API for developers. But USB HID is not a trivial thing and after a half hour of following and reading links to documentation I was no closer to talking to the pedal in a “proper” way. So I tabled that approach and returned to treating it as a file. It’s pretty trivial using Python’s file APIs to open it up for reading.

>>> hr9 = open('/dev/hidraw9','r')

Reading a few bytes at a time, we figured out the device sends two bytes upon every action. First byte is a bitfield indicating pedal status, and the second is always zero. The leftmost pedal corresponds to the least significant bit 0x1, then center pedal 0x2 and right pedal 0x4. So if both right and center pedals were both pressed, it would give 0x6. Here’s a simple Python loop that reads two bytes at a time and outputs to command line.

>>> while True:

The output if I press and release the left, then repeat for center and right pedal.


Not every action will trigger data events. There’s a small time window where separate events are collapsed together for a single notification. If I’m quick enough on the press and on release, I can push the right and left pedals simultaneously for a single 0x05 report, then release simultaneously for a 0x00 report, without any intermedia reports of 0x04 or 0x01.


This is a very promising set of experiments indicating that, if it should be necessary, we can write code to make use of this pedal in Linux without digging through all of HID API.

With that knowledge under our belts, experimentation then moved to Windows 10, which immediately recognized it as a USB HID and even shows us the name. However, it doesn’t do much without further help.

VEC USB Footpedal device is ready

Searching for answers on the web, we learned this device was designed for people transcribing audio recordings into text. The pedals allow them to control sound playback (pause, play, rewind, etc.) without taking their typing hands off the keyboard. I’m sure this is a productivity boon for its target audience, but that wasn’t us. Fortunately, the manufacturer has also released a piece of software call Pedalware which will allow this pedal to be used outside its designed scenario, like emulating keyboard keys or mouse buttons. I thought it sounded interesting enough to try.

And this is where we started getting a hint why this device has been retired… this piece of hardware’s associated software is old. Pedalware’s installer demands Windows 7 or earlier and refused to run under Windows 10.

Pedalware needs Windows 7 or earlier

At this point, Windows 10 backwards compatibility module kicked in and offered the option of running in compatibility mode. I accepted.

Pedalware needs Windows Vista compatibility mode

That was enough to get Pedalware up and running on my Windows 10 computer. Now I can assign an arbitrary keyboard or mouse action to each of three pedals.

Pedalware up and running

This worked fine in everyday web browsing and productivity applications. It is, however, too slow for gaming purposes. The aforementioned time window seen under Linux, which collapsed multiple events into a single event, manifests here as well resulting in foot click actions getting lost in high-speed gaming action.

But that’s fine, the device was never intended to be a gaming peripheral. The real problem comes from its driver software becoming unreliable as a computer goes into low-power standby. When the computer resumes, the pedal doesn’t always come back into action. And once it gets stuck, the only way to get it back is a full reboot.

This was a sign of the times when this device was designed. I remember when many peripherals would not gracefully handle a computer going to sleep, which meant I typically leave my computer running in the Windows XP/Vista/7 days. Computers have gotten more power efficient over these years but it’s still better to put them to sleep. Also, modern USB peripherals are much better about resuming from sleep.

But this pedal does not, and that’s probably why it was retired. Fortunately, my work does not require a predictably functional foot pedal, so I’ll keep it around and try using it on the occasions when it works.

Cree Dimmable LED Bulb Teardown

I brought an old LED light bulb to a SGVHAK meetup for an educational dissection. This bulb has illuminated my front porch for several years, hooked up to a light-sensitive fixture that turns on the bulb when dark, and turn it off when the sun is up. However, when illuminated this bulb has started flickering. At first it was a mild pulse that I didn’t mind very much as I don’t usually need the light myself anyway. But after a while, the blinking started getting annoying and even the bright pulses were too dark for the light to serve its intended purpose. This bulb was retired, and now we take it apart to see what’s inside.

Looking inside the cooling vents, we can see there are two circuit boards mounted at right angles to each other. Obviously there will be LEDs soldered to these boards, with a power supply at its base. Since all the LEDs pulsed together, we expect there to be a power supply failure and hope we might be able to see what component caused the problem.

Here’s the bulb intact, before teardown began.

Cree LED bulb teardown 1 - intact

Here’s the label on the bulb. This was not a bargain basement device, it was a dimmable bulb and it was also designed to be usable in damp environments as the front porch is occasionally exposed to rain. It was also exposed to outdoors wildlife, including some insects who have climbed inside and sadly died there, too.

Cree LED bulb teardown 6 - label

It was nicely sealed with no obvious way to take apart the plastic housing nicely, so out came a beefy cutter and we start cutting from top vents.

Cree LED bulb teardown 2 - first cut

Once the top vents were clipped open, we could perform some literal debugging of our device by pouring the dead carcasses out. They look like honeybees.

Cree LED bulb teardown 3 - pour out the bugs

Aside from debugging, the opened top also lets us see more details inside. Sadly, there were no visible mechanisms for easy release, so cutting continues at waist-level vents.

Cree LED bulb teardown 4 - second tier cut

Once those portions were cut away, we could see more of internals. There were fewer LED surface mount packages than we had expected.

Cree LED bulb teardown 5 - second tier removed

At this point I ran out of convenient places to cut with a hand tool, so cutting moved on to a band saw.

Cree LED bulb teardown 7 - band saw

Once the band saw cut through all around the base of transparent plastic bulb exterior, we were able to free its internals for a closer look. Surprisingly, the circuit boards connect to each other and to the base with tiny spring-loaded connectors rather than a direct soldered joint. One hypothesis is the bulb was not only designed for humid environments, it was designed to sustain vibration as well. Another hypothesis was that humid environments also imply a larger temperature swing, where spring-loaded connectors can accommodate thermal expansion/contraction better than soldered joints.

Cree LED bulb teardown 8 - disassembled

Here is the main board’s topside. Nothing appeared obviously damaged. The big electrolytic capacitor immediately drew our attention, as that is the type of component most likely to fail with age. However, the usual signs were absent. No leaking electrolyte, no bulging of the body, and no breakage in the top. With the help of our multi meter, we could tell the capacitor has neither failed open or failed short. We also measured its capacitance, which won’t be a reliable number as the capacitor is still installed on the board: we’d be measuring capacitance of the capacitor as well as the board it is installed on. But the number was roughly in the ballpark of the rating printed on its side, so it looks clear on all counts.

Cree LED bulb teardown 9 - main board front

Bottom side of the main showed no such obvious attention-getters. The small light colored surface mount component at the base might be a safety fuse, and it tested OK for continuity.

Cree LED bulb teardown A - main board back

We explore the fewer-than-expected LED modules by trying to power up a single LED using a bench top power supply. At first it stayed dark and we thought maybe the LEDs were at fault instead of the power supply. But then we realised we weren’t giving it enough power: we were surprised it took over 24 volts before a single module would illuminate.

Cree LED bulb teardown B - LED needs 24V

An explanation surfaced once we adjusted camera settings to see individual light sources inside the package: there are actually ten LEDs in each package, in a three + four + three configuration. This explains how it could be so bright with so few surface mounted modules!

Cree LED bulb teardown D - ten LED per package

At this point we’ve verified all the discrete components we understood and could test, we’ve removed dead bug remains that might have caused problems, and we cleaned up all the electrical connectors. Maybe that’s enough to bring this bulb back to life?

Cree LED bulb teardown C - back on 110V AC

Sadly, the answer was no. We hooked it up to AC power and plugged it in: it is still dim and blinky. Obviously we failed to understand how this particular bulb works – the power supply circuitry was far more complex and sophisticated than we had expected. But still, it was fun to look inside a premium (for its day) LED bulb.


Sawppy at Caltech Science for March 2019

Today Sawppy joined the fun at Science for March 2019, organized by the Caltech Postdoc Association. Since Sawppy didn’t exist yet during 2018’s event, this was Sawppy’s first visit. When Sawppy arrived at South Campus Gate, a quick check of campus directory oriented us to Beckman Mall where the event will be held.

Caltech Science for March 2019 - Sawppy at Campus Directory

Part of the journey included crossing picturesque Millikan Pond.

Caltech Science for March 2019 - Sawppy to cross Millikan bridge

As with last year’s event, the rover started the day sitting on a table for display. Of course, last year we had only a single rover. This year we have three, two of which were in running condition and could be driven for demonstration today.

Caltech Science for March 2019 - Rovers on SGVHAK table

Sawppy attracted a crowd as it usually does, and were driven around by enthusiastic children. Some of them weren’t as gentle with the control as they should be, and about halfway through the day, operator roughness by one of the kids burned out the fuse. I kept telling myself I should have spare fuses in Sawppy’s first aid kit that I keep in my backpack, but I never did put one in. I had to hack a workaround today but by the end of the night I definitely remembered to put extra fuses in the bag.

Caltech Science for March 2019 - Sawppy with burnt fuse

Group rover outings are always fun. Today’s special activity is a group climb on a grassy slope at the north end of Beckmann Hall. SGVHAK rover gave Sawppy a head start, but with faster and more power motors, combined with better traction tires, it was no contest. SGVHAK easily outclimbed Sawppy, but the important part was that we pleased the crowd with this little demonstration of rover climbing capabilities.

Caltech Science for March 2019 - Sawppy and SGVHAK Rover climbing

(Cross-posted to

Sawppy and SGVHAK Rover Will Be At Caltech Science for March

Shortly after SGVHAK Rover was completed last March, it also made an appearance at California Institute of Technology’s Science for March event organized by the Caltech Postdoc Association. The rover was well received and we’re going to do it again for this year’s event taking place tomorrow. This event is free and you can register here.

Rover Brick Demo

We were but young rover herders at last year’s appearance, and there were some durability issues that we think we’ve addressed. I’ve taken some of those lessons to heart with my own Sawppy rover, which was only a dream at last year’s event but this year will be one of several rovers joining in the festivities.

During our outing at the Downtown Los Angeles (DTLA) Mini Maker Faire, we saw familiar faces from our local friends at Caltech and also nearby Pasadena City College (PCC) and we hope to see them again this year.

The weather forecast is sunny and clear, it should be a good time!

Window Shopping BeagleBone Blue

Sawppy was a great ice breaker as I roamed through the expo hall of SCaLE 17x. It was certainly the right audience to appreciate such a project, even though there were few companies with products directly relevant to a hobbyist Mars rover. One notable exception, however is the BeagleBoard Foundation booth. As Sawppy drove by, the reception was: “Is that a Raspberry Pi? Yes it is. That should be a BeagleBone Blue!”

Beaglebone Blue 1600
BeagleBone Blue picture from Make.

With this prompt, I looked into BBBlue in more detail. At $80 it is significantly more expensive than a bare Raspberry Pi, but it incorporates a lot of robotics-related features that a Pi would require several HATs to reach parity.

All BeagleBoards offer a few advantages over a Raspberry Pi, which the BBBlue inherits:

  • Integrated flash storage, Pi requires a separate microSD card.
  • Onboard LEDs for diagnosis information.
  • Onboard buttons for user interaction – including a power button! It’s always personally grated me a Raspberry Pi has no graceful shutdown button.

Above and beyond standard BeagleBoards, the Blue adds:

  • A voltage regulator, which I know well is an extra component on a Pi.
  • On top of that, BBBlue can also handle charging a 2S LiPo battery! Being able to leave the battery inside a robot would be a huge convenience. And people who don’t own smart battery chargers wouldn’t need to buy one if all they do is use their battery with a BBBlue.
  • 8 PWM headers for RC-style servo motors.
  • 4 H-bridge to control 4 DC motors.
  • 4 Quadrature encoder inputs to know what those motors are up to.
  • 9-axis IMU (XYZ accelaration + XYZ rotation)
  • Barometer

Sadly, a BBBlue is not a great fit for Sawppy because it uses serial bus servos making all the hardware control features (8 PWM header, 4 motor control, 4 quadrature input) redundant. But I can definitely think of a few projects that would make good use of a BeagleBone Blue. It is promising enough for me to order one to play with.

Sawppy Wiring Schematic Tests Drive Digi-Key Scheme-It

When I declared Sawppy the Rover has reached version 1.0 and posted instructions online, I was fully aware of the fact that the instructions would be incomplete. Not out of neglect or malice, but out of the fact all of Sawppy is in my head and there will be places where I decided something was obvious enough not to require documentation – and learn I was wrong in that judgement.

Such is the case now. One member of RSSC accepted my invitation to build a Sawppy after my presentation in January, and submitted the feedback that I need to post a schematic of how I’ve wired up Sawppy. I previously submitted this answer as response to a comment on the project page, but more detail was needed.

The minimum electronics components for a bare-bones Sawppy has [10 * LewanSoul LX-16A] wired in parallel with each other and to [1 * LewanSoul “BusLinker” a.k.a. “Debug Board”] to translate generic USB serial to servo half-duplex serial. That translator board is connected to [1 * Raspberry Pi] via USB.

I thought this was a good opportunity to try Scheme-It from Digit-Key. It is a web-based electronics schematic editor that purports to let people quickly sketch up electronics schematics for sharing. The electrical wiring for a bare-bones Sawppy version 1.0 should be a nice easy exercise for this tool.

The terms and conditions for using Scheme-It is fairly typical for a web-based application. A Digi-Key account is required for login, something I already had from earlier purchases for electronics experiments. In exchange for free use of the software, a user also has to grant Digit-Key a license to the schematic. Not a big deal in this case, as I wanted Sawppy to be shared as widely as possible. And finally, Digi-Key reserves the right to take down this service at any time, deleting all of my data. This is irritating but not unexpected. If this is important to me I better make a copy for my own storage.

Since my sample schematic is fairly simple, it only took about an hour to go from absolute beginner to the schematic I wanted to create. I could (and did) choose to share the project file publicly via a URL, though it appears accessing the project requires logging in to Scheme-It, which required a Digi-Key account as previously mentioned. I could also export to PDF or PNG formats. The PDF export feature was unsatisfactory. Many labels were moved out-of-place making the schematic illegible. In contrast the PNG export looks OK so I’ve posted this schematic PNG to Sawppy’s project page, as well as Sawppy’s assembly instructions hosted on Github.

Sawppy V1 Schematic

(Cross-posted to

New Batteries for Thrift Store Neato Vacuums

The Neato XV-21 I found at a thrift store has bee joined by a XV-12 found by [Emily]. Both Neato robot vacuums found at thrift stores have degraded batteries. This was not a surprise as robot vacuums work their battery packs hard. Not just frequent charge and discharge cycles, but with a heavy power draw under use to run vacuum motors. This means both of these vacuums were retired by their previous owners when the battery no longer hold enough charge to perform its duties.

Neato XV-12 battery unhappy

Fortunately, this common failure also meant there’s a robust aftermarket for replacement batteries. Curiously, the economics of the markets are such that whole replacement packs can be ordered online for less than ordering individual cells and rebuilding the packs myself.

With previous experiments, I have gained confidence I can verify functionality of individual components using test mode accessible via USB port. And since this XV-12 was found with an official Neato charging dock, it’s time to install replacement batteries and test the full system.

The replacement batteries claim a capacity of 4000mAh which, on paper, is an increase from the original battery’s label capacity of 3800mAh. However, battery manufacturers play pretty loosely with these ratings so I expect the difference of 200mAh to be fairly insignificant in practice. When I took apart the original pack, I saw a thermister for monitoring temperature, an overcurrent protection fuse, and an overheat fuse. I assume the replacement pack has a thermister because the Neato computer can read it, but there’s no immediate way to tell if the overcurrent or overheat protection also exists on the new pack.

Neato XV-12 batteries old and new

With new battery packs installed, it’s time to put the robot up against the charging dock and verify the charging system works as expected. But before we do that, let’s take a closer look at this charging dock.

Cleaning Up a Thrift Store Neato XV-12

When I looked over my Neato XV-21, I thought it was far too clean to be a high mileage appliance. There were several possibilities:

  1. The previous owner was meticulous about keeping things clean (supported by the plastic protective wrap.)
  2. The Neato was barely used.
  3. A Neato is very good at keeping itself clean.

Thanks to a second Neato found in a thrift shop, this time a XV-12, we now know #3 is false. This one is well used, and very much looked it! The previous owner didn’t bother cleaning the vacuum before dropping it off at the thrift store. I have several loops of hair tangled up in the roller brush. The largest loop has even snagged what looked like furniture padding foam.

Neato XV-12 dirty brush roller

The largest loop has also tightened enough to damage the roller brush. Once I cut that loop of hair and debris off the roller brush, I see a slot cut into the rubbery blade.

Neato dirty brush roller ripped

There was also debris tangled on the motor shaft driving this roller that had to be cleaned off before the roller brush could function properly again. The cavity for the roller brush showed extensive wear from a life as a working household vacuum (above), whereas the XV-21 showed barely any wear (below).

Neato wear pattern

Those were problems found on the suction side of the vacuum. What about the exhaust side? The vacuum is generated by a fan which sat downstream from the dust bin filter, so its cleaniness would be a clue at how effective the filter was. Everything seen here are dirt particles that have made their way past the filter.

Neato XV-12 dirty vacuum motor

But even though this vacuum lived a harder life, its battery was actually in better condition and could run the vacuum computer for several minutes before fading out. As a result I was able to query all components individually using its USB port without having to hack a battery into this vacuum. All signs indicate that this robot vacuum is likely fully functional except for its battery.

And fortunately, with the arrival of replacement battery packs, we don’t need to drill holes and hack external battery packs for a full system test. We can install the new batteries into this XV-12.


Sawppy at SCaLE 17x: The Trouble with Rovers

My primary obligation for Southern California Linux Expo (SCaLE 17x) was to co-present The Trouble with Rovers with Lan Dang on Saturday afternoon. Which meant when Sawppy’s coupler broke Friday evening I had to scramble to fix it for Saturday. A rush repair job is always going to leave some details to be desired but it was sufficient to resume operation.

Sawppy will obviously be one of the visual aids present at our talk, but that doesn’t mean it gets to spend the rest of the day just sitting around. No sir, as soon as Sawppy arrived on location, it immediately started working as a roving billboard for both itself and the talk.

Sawppy Scale 17x Sat 1 - Roving billboard

It was not explicitly coordinated beforehand, but the SGVHAK rover was also equipped with advertising for our talk. Both of our rovers were out and about, pulling roving billboard duty, and occasionally our paths crossed in the hallways of SCaLE.

Sawppy Scale 17x Sat 2 - Two roving billboards

I was happy with the turnout for our rover session. While we did lose a few people who left partway through the talk, it was more than made up for by the enthusiastic people who followed along and came up to ask questions after. I had a lot of fun explaining details on what we did for both rovers, minutiae that we trimmed from the talk proper but was still interesting to our smaller and more technical audience afterwards.

Sawppy Scale 17x Sat 3 - Session

Sawppy continued to roam around Pasadena Convention Center, spreading word of my rover project to people who are excited about the possibility of building their own. Some people thought it would be their motivation to finally buy their own 3D printer, others have all the tools on hand and it’s just a matter of prioritization and finding project time. I was most gratified by a group of students from California State University San Bernardino who thinks it would be a great group project. They are exactly the target audience!

And it’s fun as always to see young children’s faces light up when they see Sawppy, some of whom were eager to take control. My favorite was this 6-year old who loved to drive Sawppy over his own toes over and over.

Sawppy Scale 17x Sat 4 - Self foot runover

(Cross-posted to

Cracked Sawppy Steering Coupler Almost Survives Full Day of SCaLE 17x

Before I took Sawppy to its first day of SCaLE 17x, I checked over all mechanical bits and found a cracked steering coupler. My first instinct was to repair my rover by replacing the coupler, but I decided against it because it was still partially functional. I wanted to see how my rover design behaves with some partially broken parts, find out how tolerant of faults it would be.

The answer is: surprisingly well! When everything is in newly assembled condition, the steering assembly could keep its wheel steering angle within a few degrees of the desired position. There is still some error due to flex in the PETG plastic through all component interfaces leading from the servo’s output shaft, through the coupler, through the 8mm steering shaft, through the steering knuckle, through the wheel bearing, the bearing axle, and finally the wheel itself.

With a cracked steering coupler, the steering assembly could still hold angle within about a 20 degree range, or +/- 10 degrees of the desired position. This isn’t great, but like its Mars inspirations, Sawppy was able to keep running with a damaged wheel. I was able to do the usual crowd-pleasing demonstrations running over backpacks and feet. While steering was a bit wobbly, Sawppy has five other wheels to compensate and maintain most of its steering authority.

I thought I’d just continue running the rover until something finally gave. And it did, just not the way I expected. Instead of a gradual degradation in rover operation, what finally killed the coupler was a child. About 6-8 years in age, the boy grabbed the steering wheel assembly in both hands and twisted hard. I heard a loud POP and that was the end of the coupler. The boy knew he was going to be in trouble and ran off, the associated adult was apologetic, but that doesn’t change the fact I now have a broken rover.

Here’s a picture from yesterday, with a partially failed coupler:

Sawppy cracked PETG coupler closeup

After abuse by careless child, here’s a fully failed coupler:

Sawppy failed PETG coupler closeup

Yesterday the coupler was cracked below the set screw. Now the crack goes all the way to the top and there’s no longer enough force to hold the heat-set insert in place. Once the heat-set insert popped out of place, its set screw no longer has leverage to grip the detent I cut on the steering shaft. A steering shaft that spins nearly freely makes Sawppy very hard to drive. I was able to move a little bit at the Tindie x Hackaday Birds of a Feather Session, but Sawppy could not perform its usual rover capability demonstrations at the meetup.

Sawppy Steering Coupler Volunteers For Fault Tolerance Test

Whenever I’m getting Sawppy ready for a public appearance, I power up my rover and drive it around a bit to make sure all the mechanical bits are functioning. I did the same for preparation for Sawppy’s appearance at SCaLE 17x and I saw the right front wheel – historically the most problematic part of any rover – is wobblier than I expected.

This usually indicates a set screw is backing out, something that was much reduced after I started using Loctite on the set screws. But when I reached towards the coupler with a wrench to turn the set screw, I realized this situation is different. The PETG plastic for the coupler has cracked.

Sawppy cracked PETG coupler closeup

For context, here’s the non-cropped version of the image to show location of this coupler in Sawppy’s front right wheel assembly.

Sawppy cracked PETG coupler

This is a new failure! And a bit of a surprise, too. My experience with PETG to date has been that it is very tough and willing to flex instead of break like my experience with PLA. It’s held up well through multiple public appearances, driven by enthusiastic children who were none too gentle with the rover. It appears we have finally reached the breaking point for PETG.

Or… have we?

The rover is still driving and nominally functioning. System performance has degraded but strictly speaking, the system has not yet failed. The crack allowed more movement in wheel steering than designed, but the movement is still constrained instead of turning freely out of control. I would call the latter case, which happened to Sawppy earlier, an actual failure. This isn’t quite it.

And now I’m curious about what potential stages of system degradation will be, so I’m going to leave the cracked coupler in place for now. I will build a replacement and have it on hand for a field repair, but the cracked coupler has just volunteered itself for a test of Sawppy fault tolerance. How much further can Sawppy go on a cracked coupler?

(Cross-posted to

Sawppy and SGVHAK Rover will be at SCaLE 17x

This year’s Southern California Linux Expo (SCaLE 17x) begins today. Four days of talks across multiple tracks focusing on topics relating to the flagship open source operating system in various ways. From small micro controllers to large cloud infrastructure. Last year’s SCaLE served as deadline and motivation for completing SGVHAK Rover, but it was only for purposes of show and tell. We couldn’t yet do a full presentation as the JPL Open Source Rover project has yet to officially launch until mid year.

But that is no longer a concern, and we even have spinoff projects like my Sawppy rover to add to the mix. Hence Sawppy will be part of our SGVHAK presentation “The Trouble with Rovers“: they’re never really finished, and their numbers keep growing. Rovers are such cool projects to work on there’s always more upgrades and evolution we can perform to make our rovers better. Lan and I practiced this talk at last month’s SGVLUG meetup and hopefully our presentation will be better for it! We’ll be presenting Saturday afternoon 4:30-5:30pm in Ballroom G.

20190214 Rovers at SGVLUG

Sawppy will also be present at the Tindie+Hackaday Bring-a-Hack meetup, under their “Birds of a Feather” event umbrella for groups to get a space and meet. It is a free event (with at least a SCaLE Expo Pass) and Sawppy will be there as representative of one of the projects with a page on This will take place Friday evening 7pm-8pm in Ballroom B.

Beyond those events, Sawppy will be generally hanging out and cruising about the event and the expo floor. There’ll probably be some time spent at the SGVLUG/SGVHAK booth, but no official scheduled events beyond the two above.

(Cross-posted to

Thrift Store Neato XV-12 Joins XV-21

I thought I was pretty lucky to find a Neato robot vacuum in a thrift store for $8. It didn’t work in the store and that’s why it was cheap, but I have since determined it was fully functional except for its battery pack. While waiting for its replacement battery pack to arrive, Player 2 has entered the game! [Emily] managed to find another Neato robot vacuum in a different thrift store. The new find is a model XV-12 and it included the charging dock for $11.

XV-12 And XV-21 A Pair of Neato

A little web research indicated that these two robot vacuums are contemporaries, both followed up Neato’s XV-11. The XV-12 is the direct successor that replaced the XV-11, and the XV-21 is a premium offering sold simultaneously with the XV-11. Aside from the cosmetic difference of purple plastic top on the XV-12, there are a few functional differences.

The cleaning brush roller is different. The XV-12 uses a bidirectional design with flat flexible plastic blades. The XV-21 uses a unidirectional design with a combination of flexible plastic blades and bristles. The XV-12 brush can be mounted in either direction – note that geared teeth to engage the toothed belt on both sides of the roller. The XV-21 is designed to spin a specific direction – brushing debris towards the center of the vacuum – and only has geared teeth on one end of the roller because it won’t work properly if mounted the other way.

Neato brush comparison

The dust bin filters are also different between these two models. While the XV-12 uses a flat sheet, the XV-21 uses a pleated design for greater surface area. This partially compensates for the more restrictive filter used in a XV-21 that captures more particles from the vacuum air stream.

Neato filter comparison

The XV-21 was sold as the upgrade model. Its roller brush with curved flexible blades and bristles combine to pick up more dirt, and its pleated filter keeps more of that dirt in the dust bin instead of passing it into the exhaust. These two differences reportedly improve vacuum capability at the cost of greater power consumption which translates to shorter run time on battery.

In addition to the design differences between the XV-12 and the XV-21, there are additional differences between these two specific thrift store finds. The XV-21 was surprisingly clean hinting at a very low usage in its previous life, but the XV-12 shows signs of a well-used robot vacuum.


Battery Replacement Options for Thrift Store Neato XV-21

With a successful all-up system test of Neato XV-21, running on hacked-up battery packs through a full vacuum cycle, we have confidence everything works on this thrift store bargain except for the battery pack. So focus returns to these NiMH battery packs.

Neato XV-21 battery pack

The default option is to buy some battery packs specifically built and sold as replacement batteries for a Neato robot vacuum. A straightforward Amazon search for “Neato battery pack” will return this “Amazon’s Choice” item at $30 for 4000mAh NiMH packs.

A tempting choice is to purchase some lithium-ion batteries that would also fit in the Neato battery bay. However, battery packs sold on Amazon are typically designed for very high draw applications like multi rotor aircraft. Batteries designed to survive such use tend to have lower energy density. Thus lithium packs that fit within the bay’s dimensions actually don’t have much significantly higher capacity than 4000mAh.

Another concern with installing lithium batteries is the fact the Neato’s on board charging circuits are designed for NiMH battery cells, which has a different charging profile. Charging lithium cells as if they were NiMH cells risks damaging the lithium cells and possibly lighting them on fire.

There is, however, this item which are lithium replacement packs intended and designed as an upgrade option for Neato vacuums. Not only are they sized appropriately to fit, they also have an integrated battery management system. Presumably, the circuit will make the Neato brain think there’s a NiMH battery pack installed but treat the lithium cells properly. At 4400mAh it offers 10% higher claimed capacity relative to default option, but at over double the cost, the cost/performance ratio is poor.

There is also the option to purchase new NiMH battery cells and rebuild the battery pack myself, reusing all the associated parts from the existing pack. I had expected this to be the lowest-cost option by supplying my own labor, but when I searched for NiMH battery cells in 4/3A form factor with 4000mAh capacity, I was surprised to find that they were selling for more than $3 per cell. There are 6 cells per pack and a Neato requires two packs, for 12 total cells. This means buying raw cells and rebuilding them myself would cost over $36, more than just buying a prebuilt pack from Amazon!

With this little bit of research into lithium upgrade option and rebuild option, it looks like the default $30 option is the best way to go. But before that replacement battery pack arrived, my Neato got a friend!

Mounting External Batteries on Thrift Store Neato XV-21

Using small batteries I hacked into existing battery bays, I was able to query sensor status and command individual motors. However, those small batteries were not powerful enough to run multiple motors simultaneously, which meant a full system test would not be possible until larger batteries are installed. At this point I could order some Neato-specific replacement batteries and have decent confidence it will work, but I would like additional confirmation before I spend money.

But I didn’t have any batteries that were more powerful and still small enough to fit within Neato vacuum’s existing battery bays. This meant batteries had to be installed externally. And if they’re going to be external, I might as well go with the biggest batteries I have on hand: those I purchased for Sawppy the rover.

But where could I install those batteries?

Neato XV-21 with two big power packs

The most obvious place: is to put them on top of the dust collection bin. This is a popular location for Roomba battery retrofits, because it preserves weight balance and does not hinder Roomba operations. However, it won’t work for a Neato: this position blocks the line of sight for the laser distance scanner.

Neato XV-21 with two big power packs on top of dust bin

Installing the batteries on the front bumper would be out of lidar line of sight, and might help improve vacuum performance because their weight would help push the dirt brush roller into the ground. But this would change the behavior of front bumper which might confuse vacuum mapping algorithms, and using fragile batteries as your front bumper is never a good idea.

Neato XV-21 with two big power packs in front of bumper

If we put batteries off to the sides, it preserves front clearance but now it interferes with side clearance. The vacuum would no longer be able to follow along walls closely to vacuum near walls if the batteries are attached to the sides.

Neato XV-21 with two big power packs along sides.jpg

Installing behind the vacuum disturbs the weight balance – battery weight is now trying to lift the brush roller off the ground. The back is not flat, making installation difficult. And that circular shape is there for a reason – its clearance helps the robot turn in tight spots. Batteries install behind the robot would get bashed against obstacles as the robot turned.

Neato XV-21 with two big power packs behind

And obvious we don’t have any way to mount batteries on the underside of the vacuum, as there is only about 5mm of ground clearance. That exhausts all the potential directions we can go for external mounting.

Time to get creative.

Rethink top mounting, we recognize the problem is that we can’t block laser distance scanner’s line of sight. It looks out all around the top of the vacuum, except for one place: the raised protective cap above the lidar housing. Batteries mounted on top of that cap would not block laser scanner’s line of sight.

Neato XV-21 with two big power packs above lidar

Wires were run from battery compartment, which required drilling two small holes. To keep the power wire out of sight of lidar, the wires were routed through existing grooves on top of vacuum body and then followed existing  support pillars for lidar housing. This way, the wires should not introduce additional blind spots.

Neato XV-21 wire routing for two big power packs.jpg

With this hack, the robot vacuum can run on my pair of Sawppy rover batteries, which are plenty powerful enough to run all vacuum systems simultaneously. Now this little Neato is alive and can run through a full vacuum cycle, verifying that all systems worked.

Neato XV-21 up and running with two big power packs

Obviously, this won’t be the final long term solution. For one thing, Sawppy wants its batteries back. For another, the additional height on top of the robot hampers its ability to get under furniture for vacuuming, and the exposed wires are vulnerable to tangling on protrusions. What we need next are batteries powerful enough to run a Neato and fit within existing battery bays.

Sending Commands to Neato XV-21 Via USB

I’ve managed to establish a serial connection to my Neato XV-21 robot vacuum’s USB port, putting it into test mode and querying sensor status. The next step is to start issuing commands to see if individual components respond. We left off on querying control panel user interface buttons, so the next test is to see if I can draw my own user interface on that control panel screen. Typing in help setlcd retrieved the following information:

SetLCD - Sets the LCD to the specified display. (TestMode Only)
BGWhite - Fill LCD background with White
BGBlack - Fill LCD background with Black
HLine - Draw a horizontal line (in foreground color) at the following row.
VLine - Draw a vertical line (in foreground color) at the following column.
HBars - Draw alternating horizontal lines (FG,BG,FG,BG,...),
across the whole screen.
VBars - Draw alternating vertical lines (FG,BG,FG,BG,...),
across the whole screen.
FGWhite - Use White as Foreground (line) color
FGBlack - Use Black as Foreground (line) color
Contrast - Set the following value as the LCD Contrast value into NAND. 0..63

This is enough to draw simple test patterns, but it isn’t enough for me to put up legible text prompts for users. This was not a surprise as I understand this mode to be a diagnostics console and not intended to facilitate a completely new UI like what I wish to do. Still, I can probably convey some simple if cryptic information by drawing horizontal and vertical lines. The valid range is 0-127 inclusive. And while vertical lines across that entire range are all visible, horizontal lines beyond 124 seem to go under bottom lip of display bezel and not visible.

setlcd bgwhite
setlcd hline 20
setlcd vline 50
setlcd vline 100

Neato Line Art

I’ve already played with turning the laser distance scanner on and off. The next most important thing to get running on this chassis are the drive wheels. If I can’t make the robot move using this interface, nothing much else matters. Here are the commands listed under help setmotor:

SetMotor - Sets the specified motor to run in a direction at a requested speed. (TestMode Only)
LWheelDist - Distance in millimeters to drive Left wheel. (Pos = forward, neg = backward)
RWheelDist - Distance in millimeters to drive Right wheel. (Pos = forward, neg = backward)
Speed - Speed in millimeters/second. (Required only for wheel movements)
Accel - Acceleration in millimeters/second.
(Used only for wheel movements. Defaults to 'Speed'.)
RPM - Next argument is the RPM of the motor.
Not used for wheels, but applied to all other motors specified in the command line.
Brush - Brush motor forward (Mutually exclusive with wheels and vacuum.)
VacuumOn - Vacuum motor on (Mutually exclusive with VacuumOff)
VacuumOff - Vacuum motor off (Mutually exclusive with VacuumOn)
VacuumSpeed - Vacuum speed in percent (1-100).
RWheelDisable - Disable Right Wheel motor
LWheelDisable - Disable Left Wheel motor
BrushDisable - Disable Brush motor
RWheelEnable - Enable Right Wheel motor
LWheelEnable - Enable Left Wheel motor
BrushEnable - Enable Brush motor
SideBrushEnable - Enable Side Brush Motor motor
SideBrushDisable - Enable Side Brush Motor motor
SideBrushOn - Enable the Side Brush
SideBrushOff - Disable the Side Brush
SideBrushPower - Side Brush maximum power in milliwatts

The first few attempts – using just individual commands – were met with either errors or no movement.

setmotor lwheeldist 100
No recognizable parameters

The first successful command that triggered movement was one where I specified three parameters on a single line: left wheel distance, right wheel distance, and speed.

setmotor lwheeldist 200 rwheeldist 200 speed 100

The robot moves! This is great news, but we still have two more motors to play with. First up is the brush roller: I had expected the motor to be a digital on/off affair, or maybe something I can command with a particular motor power level. I was quite pleasantly surprised it can be commanded to a particular RPM because it implied a more sophisticated closed-loop feedback control system.

setmotor brush rpm 750
Run Brush Motor @ 750 RPM

The final motor control for vacuum suction fan was a little frustrating. I had no issue turning it on with setmotor vacuumon and then back off with setmotor vacuumoff. But I haven’t yet figured out the right syntax to command it to spin at a partial power level.

setmotor vacuumspeed
Value required for option VacuumSpeed
setmotor vacuumspeed 50
No recognizable parameters
setmotor vacuumspeed 50%

Invalid Command: 'setmotor vacuumspeed 50%'

I’ll update this post if I ever figure it out, but for now it is enough that it spins.

With this set of tests, I have determined that all individual components are functional, but only in a limited context. The limitation is because I could power just one device at a time with the small batteries I have installed. What I want next is a full system test. And for that, I will need to install more powerful batteries.

Disney Infinity Base and Figurine Teardown

On the one hand, I love many Disney properties. On the other, I’m very clear Disney wrings every penny out of their fans. Disney Infinity was a video game where new characters and capabilities are acquired via purchase of physical figurines. Advancement in the game requires a steady stream of new figurine purchases. As much as I love both video gaming and Disney properties, that was too much of a money grab for me to put up with. Apparently enough people thought the way I did, because Disney shut it down for not making enough money.

Ironically, that announcement is why I now have a Disney Infinity starter pack: once the announcement was made, these kits went on the clearance rack for drastically reduced prices. I was not interested in paying their full price, but I can certainly spare $5 for a gaming peripheral with no future just so I could take it apart! It took a while for me to get around to this project, which finally happened at a recent SGVTech meetup.

Disney Infinity 1 intact

This starter pack came with the system base, Merida, and Stitch. Based on how the game worked, we expected a RFID-based system. That implies RFID chips in the bottom of these figurines, and the USB-connected base has coils to read them. Expectations on these fronts were met but there were a few surprises on the way.

The plastic top of the base were held with a few clasps that were easily broken. Once removed, we could see three white PCBs each with what appears to be a surface mount LED on top, and a green PCB with connections to each of them and the USB cable.

Disney Infinity 2 top removed

When we flip over one of the white PCB, we could see it is a simple single layer design and its RFID coil is visible. The straight lines towards the middle are for driving the LED.

Disney Infinity 3 rfid pad flipped

The control board is a more typical multi layer board. The biggest chip on board is from the STM32 family, specifically the STM32F072C8T6. Typing the numbers printed on top of next two larger chips into a web search didn’t return any useful results.

Disney Infinity 4 STM32 in charge

The LED on each white PCB appears to have four leads. When we saw four leads our first thought was an addressible LED with power, ground, data, and clock. Then we remembered this is a toy built to low cost: it’s more likely a RGB LED package with a common anode and three cathodes, one per color. Either that or the reverse with a common cathode and three color anodes. The ‘+’ labelled on its PCB hinted at a common anode design, which was confirmed with a quick test using a bench power supply putting power on some exposed pads.

Disney Infinity 5 pad LED illuminated

Aside from the RGB LED, there’s not much of interest from these three white PCB I could pull off and reuse. The main green PCB was more sophisticated, and there were exposed pads on the bottom that hint at the possibility of reprogramming the STM32 for something fun, but that’s beyond my current skill level. (This guy can probably do something with it.) The part of the board with best potential for reuse is its USB connection. It gives me a USB-A connector for plugging into a computer, and the other end is a nice modular connector with 2mm pitch. This will be useful the next time I want to hack a standard USB cable onto a device.

Attention then turned to the other part of this system: the figurines. Once the clear plastic portion was removed, its RFID sticker is accessible. Sadly, Stitch’s arms did not survive the process of prying apart his base.

Disney Infinity 6 Stitch sticker removed

A closeup of RFID sticker showed most surface area is antenna, and that tiny black dot is a chip with the secret code to unlock a Stitch character in a Disney Infinity game. People online have tried to hack these bases with little success. Given that the revenue stream comes from selling figurines, there was a robust security scheme to protect the game against counterfeit tags. I was not interested in exploring the digital side in any case, this was strictly a physical teardown.

Disney Infinity 7 RFID sticker closeup

In her movie Brave, Merida was guided by little blue glowing wisps. In the figurine, a wisp floated by Merida’s foot. As a ghostly entity, it was fittingly cast in translucent plastic.

Disney Infinity 9 Merida wisp top

But there was an extra detail: the translucent plastic went all the way through the opaque parts of the stand, so it could pick up LED illumination from the USB base. When it glowed with a blue LED, the wisp would glow blue just like in the movie. This bonus showed the artists were thinking about how to best take advantage of this medium. Too bad such creative thoughts were infrequent (Stitch had no such attraction) and probably went unnoticed by most buyers.

Disney Infinity 8 Merida wisp bottom

The final piece – hexagonal tiles for some purpose or another – were unremarkable. Once the transparent and opaque pieces were pried apart, a similar RFID tag could be removed. I didn’t see any interesting possibilities for reuse.

Disney Infinity A Merida hexagon

Query Neato XV-21 System Status Via USB

With the experimental batteries in place, the computer boots up and stays up for longer than three seconds. I tried to run a vacuum cycle but that was too much for these batteries to handle, so for now I’ll stick with digital exploration starting with the standard UI to dump revision information on components inside this particular Neato XV-21 robot vacuum.

Neato XV-21 info

After that, it’s time to go exploring through its USB serial port diagnostics!

I went straight to the most interesting component: the laser distance scanner module. First I had to put my vacuum into test mode with testmode on. Followed by setldsrotation on to turn on the motor that sweeps the laser. And finally, fetch a set of laser distance data with getldsscan. This gave me a large set of numbers. According to the legend given in the first line of the response, a distance and intensity number per degree of sweep. Partial excerpt below:


Future experimentation will determine what range of distance values are typical, similarly for intensity values. A quick web search failed to find a reference guide for error hex codes, but hopefully there’ll be a small set that I can infer from context. More exploration to come!

In the meantime, I repeated the getldsscan command to verify the values are getting updated. They were – I received a similar but slightly different set of numbers. Hooray! the most important sensor looks like it is functioning.

Next item on the exploration list: querying analog sensor values with getanalogsensors.


I see three distance sensors – wall and two drop sensors, one in each front corner. It’s not immediately clear what “Mag” in left and right “MagSensor” referred to. Do they detect magnetic fields? Or are they measuring magnitude of something? Bottom three lines indicate the vacuum sensor suite includes a three-axis accelerometer which can measure in units of thousands of G, implied by a Z value nearly 1000 in this vacuum sitting on the floor. Remainder of the values are related to power management.

The 3-axis accelerometer values above from getanalogsensors partially overlap with results of getaccel. As the name indicates, this one is completely focused on accelerometer readings and includes results of additional calculation in the form of pitch and roll in degrees and a sum of acceleration vector.

PitchInDegrees, -0.64
RollInDegrees, -0.53
ZInG, 1.079
SumInG, 1.079

The list of digital sensor values from getdigitalsensorsis shorter, and for whatever reason, labelled in all capital letters.

Digital Sensor Name, Value

Here we can see whether the dustbin is installed, whether either or both wheels are at full extension, and it looks like there are four switches associated with the front bumper. The top line shows if a charging plug is connected, but that’s only one of many parameters around power management. Most of the rest are in getcharger.


If I were to create my own control logic for driving my Neato around, the most important parameter here is FuelPercent. I’ll have to be responsible about not draining the battery too far, beyond that I can leave the rest in the capable hands of Neato’s existing battery management system. Speaking of power consumption, the biggest drains are the motors, and I can monitor them all with getmotors.

Charger_mAH, 0

Not very exciting at the moment, because all motors are at a stop. I imagine these numbers will get more interesting once the robot gets underway.

One final discovery in inputs: when in test mode, the user interface buttons on the top of the robot no longer trigger their usual functions. I could check for status of all five buttons via getbuttons which implies I could use these buttons in my own projects without worrying that I’ll trigger the default vacuum behavior. Cool!

Button Name,Pressed

But if I want to actually have my own user interface using those buttons, I would need to also display my own information on the LCD. Which brings us to phase 2 of playing over USB: start sending commands to see if components follow orders.

USB Serial Communication with Thrift Store Neato XV-21

My Neato XV-21 robot vacuum now boots up and stays running on a pair of old remote control helicopter batteries. This is a vast improvement over its comatose state when I found it in a thrift store. I pressed the start button to see if it’ll actually vacuum, but spinning up the motors drew too much current and aborted. Looks like these batteries are only good for probing electronics, which is still more than what I had before. And a good incremental step forward.

A few web searches on Neato technical details all pointed to posts on “Neato Robotics” forum on I guess this is where all the Neato robot tinkerers hang out. From this forum I learned of a tool for Neato maintenance that can help communicate with the vacuum as well as uploading firmware updates. Unfortunately, this forum also shared an update that Neato has taken these tools off their website. Without them, plugging the vacuum into my laptop running Windows would only result in a device without a driver.

Neato mini USB cable connection to laptop.jpg

On a lark, I rebooted my laptop into Ubuntu Linux and plugged in the vacuum. There were never any Neato drivers for this operating system, and I was curious what I could see via Linux tool dmesg.

[10547.714901] usb 1-1: new full-speed USB device number 25 using xhci_hcd
[10547.866228] usb 1-1: not running at top speed; connect to a high speed hub
[10547.876232] usb 1-1: New USB device found, idVendor=2108, idProduct=780b
[10547.876235] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[10547.876237] usb 1-1: Product: Neato Robotics USB v2
[10547.876239] usb 1-1: Manufacturer: Linux with fsl-usb2-udc
[10547.881256] cdc_acm 1-1:2.0: ttyACM1: USB ACM device

Well, that was more straightforward than I had expected. The ACM in ttyACM1 here stands for abstract control model. The operating system sees a communication device where all control is handled by the device, and all I had to do is treat it like a serial port. It’s not a true serial port, but close enough the technical differences aren’t important right now. What matters is the fact that I can run minicom --device /dev/ttyACM1 and issue a simple call for help. We are in business! The channel has been opened to talk to a Neato vacuum brain and see what it says in return.

Help Strlen = 1792
Help - Without any argument, this prints a list of all possible cmds.
With a command name, it prints the help for that particular command
Clean - Starts a cleaning by simulating press of start button.
DiagTest - Executes different test modes. Once set, press Start button to engage. (Test modes are mutually exclusive.)
GetAccel - Get the Accelerometer readings.
GetAnalogSensors - Get the A2D readings for the analog sensors.
GetButtons - Get the state of the UI Buttons.
GetCalInfo - Prints out the cal info from the System Control Block.
GetCharger - Get the diagnostic data for the charging system.
GetDigitalSensors - Get the state of the digital sensors.
GetErr - Get Error Message.
GetLDSScan - Get scan packet from LDS.
GetMotors - Get the diagnostic data for the motors.
GetSchedule - Get the Cleaning Schedule. (24 hour clock format)
GetTime - Get Current Scheduler Time.
GetVersion - Get the version information for the system software and hardware.
GetWarranty - Get the warranty validation codes.
PlaySound - Play the specified sound in the robot.
RestoreDefaults - Restore user settings to default.
SetFuelGauge - Set Fuel Gauge Level.
SetMotor - Sets the specified motor to run in a direction at a requested speed. (TestMode Only)
SetTime - Sets the current day, hour, and minute for the scheduler clock.
SetLED - Sets the specified LED to on,off,blink, or dim. (TestMode Only)
SetLCD - Sets the LCD to the specified display. (TestMode Only)
SetLDSRotation - Sets LDS rotation on or off. Can only be run in TestMode.
SetSchedule - Modify Cleaning Schedule.
SetSystemMode - Set the operation mode of the robot. (TestMode Only)
TestMode - Sets TestMode on or off. Some commands can only be run in TestMode.
Upload - Uploads new program to the robot.

Replacement Battery Test for Thrift Store Neato XV-21

My Neato XV-21 vacuum couldn’t power on when I found it in a thrift store, and the problem (or at least, the first problem) was its battery pack: it could only deliver enough power to boot up the onboard computer and run it for about three seconds before its voltage dropped and the computer shut down again.

In order to assess the rest of the vacuum, I need to find a replacement power source. Since the actual condition of vacuum components are still unknown, I’m not inclined to spend money buying batteries specific to a Neato robot vacuum. The next experiment, then, is to wire up something out of batteries already on hand. I looked through my pile of batteries to see which would satisfy the following criteria:

  • Delivers roughly 7.2 volt power of a six-cell NiMH battery.
  • Fits within Neato battery compartment.
  • A pair of identical batteries, one for each bay.

The winner was a pair of batteries I had for my E-Flite remote control helicopter. The aircraft itself had long since been crashed and trashed, but I kept its batteries. Two cell lithium polymer batteries have nominal voltage of 7.4 volts, within operational range of 6-cell NiMH batteries. Physically they were small enough to fit within the battery compartment, but at 800 mAh their power capacity is too low for full vacuum operation. They were designed to deliver high power to fly a small helicopter toy though only for a few minutes. Ideally they can run the vacuum motors briefly to verify their operation, but mostly I just need them to run the Neato computer for more than three seconds.

To connect these batteries, I first disassembled the old tired original battery pack. Before disassembly, I noticed a rectangular bump visible in the battery pack. I had thought this was the thermistor but I was wrong. It appears to be a temperature safety fuse. There was also an over-current protection amperage fuse in the pack. NiMH cells are relatively safe but it’s still good to see additional safety measures inside these packs.


I needed the battery pack’s wiring harness for my battery experiment, so it was cut free. I kept the temperature monitoring thermistor and wired the positive and ground battery power wires to a JST-RCY connector that will mate with my E-Flite battery pack.

E-flite Pack for Neato Vacuum.jpg

Once soldered, I connected the pair of batteries and plugged them into my Neato XV-21.

Neato XV-21 with adapted E-Flite LiPo batteries

I was greeted by the same boot-up screen I saw before, but this time the screen stayed on instead of flickering off after three seconds. Now it’s time to try talking to the vacuum.