Author: Keegan

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… 

Work has continued on the occupancy sensor to help with social distancing, I switched from Arduino’s connected using NRF24L01 modules to ESP32s that have a built in Wifi chip.  The former was an unpredictable pain in the backside and the latter just seem to work!

I was due to install these on Saturday but ended up staying home as I wasn’t feeling well (just a cold), and as I’ve a bit more time I’m tidying up.
I’ve decided to use permaproto boards, these are essentially breadboards that you can solder to to make permanent, and they work a treat.  The first attempt worked but the wires were weak and snapped off before I could hotglue them for strain relief.  I managed to move things around on the board and there is just enough room so solder the plugs down.  

One trick I remembered from using strip board at school was that you can drill out spots on the track to separate them.  For the two sonar sensors, the 4pin plugs, they have 5v, gnd, and trigger which are common between them but have an echo pin each.  By splitting between the two sockets I could make better use of the board.

I also redesigned the enclosures, they look much nicer that the cuboid ones I previously had and I threw my logo on there for good measure.  With my Chonky 3d printer the boxes print in 1h20 each so it’s already proving its worth.  

Finally, the last photo.  The chip that popped was a 7805 voltage regulator, the idea is I can run 12v across long wires and though the voltage will drop over that distance there will still be enough potential to get 5v out of it.  Turns out you can’t just whack one of these chips in and hope for the best…

It got very hot, started to brown out, the popped with an almighty bang!  Yeah, I needed new trousers…

I’ve ordered some other regulators that are plug and play which will do the trick and were designed by someone who knows what they’re doing.  Hopefully no more surprises and I can get this installed and done next weekend.

Work is continuing on the Roomba, I’m hoping to have a video for that this weekend, but I thought I’d share the new logo for the company.   The existing and previous logos have been thrown together based on doodles but I’m getting help with these. 

The bot lacks a name at the minute, it’ll come to me soon no doubt. 🙂