Neave Engineering Ltd

47 out of 56 turned out to be great! One pack had suffered water damage and had to be disposed of.  I’ll be using these across various projects, shortly on the Roomba, and they’ll be incredibly useful.   I’ll definitely be keeping an eye out for more, the packs the grey cells came from especially.  A good few hundred quids worth easy as they’re almost all over 2.5Ah and essentially cost what you all pledged last month so thanks for giving me the power to continue!  

Yeah, the puns aren’t going to get any better and I apologise for nothing! 🤣

Continuing work on the controller, I’m tidying up the rats nest that is the wiring.  The majority of this controller, and MacFeegle Prime for that matter, was designed or put together while massively sleep deprived or in a rush.  

Now I’ve a bit more time, because with PiWars 2020 postponed a few months I *clearly* didn’t have any back then, I’ve decided to use some PermaProto board and actual plugs to make it considerably tidier.

I started off by taking stock of what’s there, other than the mess.  I have a bus bar along the bottom that gives power and ground to the various switches and potentiometers, other than that everything just uses jumper wires to the various headers.

One thing I wanted to do was swap out the potentiometer that was on there for a snazzy rotary encoder that has an RGB LED and a push button too!  This does mean more pins but I’ve just enough so all good there.

Next up I mocked up all the parts in excel alongside the pins, it’s a nice way to keep track of things like this.  I then put all the sockets and whatnot on to some breadboard to make sure it all fit.

Yeah, so I keep forgetting that some of my breadboards are wider than permaproto by one row so when I tried to move over the buggers didn’t fit!

Thankfully I have some right angle sockets so I was able to move things around a bit, everything just fits but fit it does!

Having taken way longer than expected I’ve run out of spoons a little so rather than trying to push through and mess it up I’ll pick this up tomorrow.  Next post I’ll have everything wired in and the Teensy updated with code to use it all!

Officially on holiday for two weeks!

Next up on the robot, after getting the wheel encoders working, are the bumper triggers.  These are essentially the same as the wheel encoders so I can reuse the circuit I put  together and they’ll be on interrupt pins too.  Thankfully the Arduino Mega I upgraded too has another two spare.

The reason for using triggers is that these act as an estop of sorts, as soon as you hit something the robot needs to Do A Thing.  There’s a video I saw an age ago of one of the engineers tearing down a Roomba and explaining how and why they built it in certain ways and he said they used the left and right triggers together to figure out where the bumper was hit.  If only the left or right trigger it’s one of those two sides but if they both trigger you can use the difference between them to figure out roughly where on the bumper was hit.

The benefit here is that if you know where you struck something you’ll be able to react more accurately.  For example, if only the right trigger is activated then you can make an educated guess that you only need to move a little left after backing up but if it’s somewhere in the middle you’d need to move a lot sharper to either side.

Something else I’m doing is replacing the battery pack with three Lithium Ion cells from the scavenged laptop batteries.  I have a couple of 3-cell caddies for them which will give ~12v which will be enough for this robot.  I dug out the connection from the existing battery to the power switch and it was held in place with hot glue!  I’m no longer hacking, I’m continuing a proud iRobot tradition. 😛

I’m hoping to have a video in the coming week as with the wheel encoders and bumpers I’ll be able to get basic movement working, there’s a distance sensor on the right hand side which should just need an analogue read on the Arduino too.  There are a lot more sensors on board, each wheel has a “lifted” sensor and there are a bunch of downward-facing sensors on the bumper too, but I’ll deal with these in time.  The downward facing ones are cliff sensors so that it doesn’t fall down stairs, for now it’ll be supervised anyhow so not too much of an issue.

I’ve a few projects in the planning so thought I’d go back to basics and do some work on my NE-Thing controller.  All code for this one so not much to see, the code is a bit hacky at the minute too so not sharing that yet out of sheer embarrassment…

For PiWars earlier in the year I had the remote configured so that the Teensy that was monitoring the switches and joysticks was creating messages and sending them directly to the robot via ROS (Robot Operating System).  This was great as it removes a step on the Pi but means that you need to hard code the controller for each thing you want to control.

Instead what I’ve done is use one of the features of the Teensy which is to present to the computer as a joystick.  What this means is that I can have code on the Pi that will read the events from the “joystick” and translate it into whatever commands are needed.

It’s not quite as elegant but is far more versatile for sure as I can deploy the joystick code in a ROS package.  There’s a dodgy connection on a couple of the switches so I need to sort out the wiring and add in a rotary encoder.

This was the original plan for the joysticks so I’m going full circle, soon MacFeegle Prime will ride again!

I’ve a few projects in the planning so thought I’d go back to basics and do some work on my NE-Thing controller.  All code for this one so not much to see, the code is a bit hacky at the minute too so not sharing that yet out of sheer embarrassment…

For PiWars earlier in the year I had the remote configured so that the Teensy that was monitoring the switches and joysticks was creating messages and sending them directly to the robot via ROS (Robot Operating System).  This was great as it removes a step on the Pi but means that you need to hard code the controller for each thing you want to control.

Instead what I’ve done is use one of the features of the Teensy which is to present to the computer as a joystick.  What this means is that I can have code on the Pi that will read the events from the “joystick” and translate it into whatever commands are needed.

It’s not quite as elegant but is far more versatile for sure as I can deploy the joystick code in a ROS package.  There’s a dodgy connection on a couple of the switches so I need to sort out the wiring and add in a rotary encoder.

This was the original plan for the joysticks so I’m going full circle, soon MacFeegle Prime will ride again!

Things have slowed down this week as I’ve had to go full time to help on a project at work, I’ve two weeks off from Monday though which I’m very much looking forward to!

In the mean time I’m working through a box of laptop batteries I bought on ebay. They’re great to scavenge batteries from for robots and other projects, that box has promise of up to 54 cells too. Good ones can cost £4 each, it’s pot luck what I get but for £30 for the box it’s worth it as even if only half are good that can be a £100s worth!

The ones I’m testing at the minute have been really drained but slowly coming back to life, fingers crossed for a good haul. They usually take over night to test so this is slow going…

I’ve been working on the robot controller over the past few days, mostly on the software, but added a snazzy new wallpaper too.

I’ve been trying to get ROS Noetic installed on it without any luck, I tried a few different distributions and hit different errors each time.  The penny finally dropped when I tried to install Ubuntu Mate, “CPU 0 is not supported”.

It turns out what I thought was a Raspberry Pi 3+ was a Raspberry Pi 3, a subtle but very important difference as it uses a different CPU entirely!

I’ve switched over to a ridiculously overpowered Raspberry Pi 4 for now, it runs a 64bit ARM processor which ROS will install on fine, and it’ll do for now.

I also installed the PiJuice HAT for the Pi, it has a battery onboard and software that lets you monitor the charge level.  It’s much tidier than the DIY option I was going to go with and has a real time clock built in too.

One slight issue with this HAT is that I didn’t design for it and the case lid can’t be refitted.  The whole controller needs another look design-wise anyhow so I’ll factor it in with the rebuild.

It’s done! Ish…

I need to mount the PSU for both printers outside of their enclosures, they are pretty big parts that need printing but that’s what Chonk is for after all.  

In order to make both fit I’ve removed the Multimaterial Unit from my Prusa, I need to give it time to figure out how to actually use it still so figured it’s better to just get this done and do that in the future when Chonk is more stable.  

After all, perfect is the enemy of done and I need to be better at remembering that.  Now that it’s done I can forget about it for a while but take advantage of it making my office much tidier.  

Also, exciting news, I’ve just passed the point where all you lovely people are paying for my robotics training!  I’m a member of Robot Ignite Academy who have excellent online training for ROS (Robot Operating System), this is going to make a big difference for sure!  

Thanks again to you all 🙂

Yesterday I mentioned I was working to get the encoders working so we can measure the speed the wheels are turning at, I also mentioned I could get the encoders working but not at the same time as the motors.  You’d think that’d be a clue but apparently not!

A bit of background.

I’m using an Arduino Leonardo and a motor shield from Adafruit: https://www.adafruit.com/product/1438 

This shield is brilliant, it allows you to very easily control up to four motors.  I’d already burned out one of the two controllers on the board but I’ll detail that when I get around to controlling the sweeper brush in the future.  Spoiler alert, it used more power than the chip can handle and the magic smoke was released…

Regarding the encoders, in order to count them accurately we use a feature of the Arduino which are interrupts pins.  When a change is detected on these pins, the other functions of your code will be stopped and whatever you assigned to the interrupt will run instead.  In my case I have two interrupts, one for each encoder, each of which incremented a counter.  Measuring how fast that changes gives us the speed.

This worked a treat in isolation but when I used the motor shield it all stalled, I’ve discovered why.

As they are special the Leonardo has a limited number of pins which can be used for interrupts.  0, 1, 2, 3, & 7.  0 and 1 are used for the serial port so I used 2 & 3 instead, I completely forgot these are used by the motor shield!

I switched over to pin 7 and lo and behold it worked!  With the Leonardo is means I can only monitor the speed of one motor which isn’t much use.  Using an Arduino Mega gives us four more to play with on different ports, I’ve one somewhere in my parts boxes so will have to dig it out.

Very glad to at least figure out why this wasn’t working, happy to share that lesson too! 

I’ve been working on getting the wheel encoders working today and I’ve got a circuit that works. It turned out that it uses a photodiode rather than a light dependant resistor. An LDR changes resistance depending on how much light hits it, they’re often used in night light sensors and in phones to dim the screen at night. Photodiodes work very differently.

A photodiode generates a small amount of voltage when light hits it, kinda like a solar panel, so you need to wire it up like a switch to measure on or off.

Inside the wheel housing is a wheel with cutouts that sit between the light source, a red LED, and the photodiode. This wheel has 32 cutouts, knowing this we’ll be able to count how many times the input shaft has rotated.

The wheel has another gearbox internally, not sure what the reason is at the minute, but we should get at least a few hundred pulses per revolution of the wheel itself which should be ideal for odometry.  It was designed for this after all but still nice to have confirmation.

For reasons unknown I can count the movement of one wheel or the other at the minute, not both at the same time, which is incredibly annoying and I can’t see why!

No doubt it’ll take hours and be obvious once I find it but that’s par for the course…