Introducing - The Mark 2

With a fully working motor driver now in my possession I decided to take this time to update and revise the chassis for my robot based on my experiences with it so far. Having dropped support for my large all-terrain wheels I've been able to increase the width of the chassis and, for now, I've decided to drop the little side tabs as well, mostly to make it easier to cut!

The Mark 1, as I guess I should call it now, had the battery and motor driver haphazardly mounted on top of the robot with wires everywhere. This isn't very pretty, or safe, and didn't leave any room for adding any sensors for the autonomous challenges. To deal with this problem I perused the selection of project boxes available from my local Maplins and selected one that both the motor driver and battery would fit inside.

After some trimming and hole drilling the motor driver was mounted inside, with leads coming out of the side to connect up to the motors, and the battery slipped in next to it. As this is an enclosed space its possible that the heat from the motor driver will build up inside it, but for now I'm leaving it as is and will keep an eye on the temperature. If needed I can always add some ventilation and a fan.

The project box itself has a removable lid that is held in place by four screws which,  with the lid removed, make excellent mounting points. Four quick holes drilled in the chassis and the project box is bolted to the underside of the robot. It fits in nicely between the motors, but does reduces the ground clearance of the robot which may cause problems for the obstacle course.

The finishing touches involved cutting a hole in the side to access the Arduino's USB port, for ease  of reprogramming, and cutting another hole in the chassis to pass through the power and I2C  connection to the Raspberry Pi. I also decided to switch over to my smaller wheels, mostly to check nothing will end up dragging across the floor.

The Mark 2 feels a lot more solid and robust than the Mark 1 did, with the majority of the robot's top available for installing sensors and any other components that will help in the PiWars challenge. So with some quick changes to the Arduino's source code to support the newer motor driver it was time to go for a test drive.

As I had full control over the motors this time it was a much more successful test run. Compared to my entry from last year Optimus Pi is already much more controllable, due to the lower geared motors and reduced weight, which bodes well for the autonomous challenges this year (I didn't manage to do any of them last time!).

With a working, controllable robot I can now turn my attention back to the software side of things, at least until my next batch of hardware components arrive!

Leo

A whole new - Motor Driver?

In my last blog posting I was having trouble with the original motor driver I'd selected and had decided to order a different one. The new model is the Pololu dual VNH5019 motor driver and I spent this weekend soldering and connecting it up (At least when I  wasn't busy playing with BB-8).

The fully assembled board

This board has a couple of advantages over the previous one, it uses a newer motor driver chip, can handle a wider range of input voltages, has separate break out pins for running the board without an Arduino, passes through the extra SDA/SCL pins on the Arduino, allows the Arduino to be powered from the battery and comes with a software library to make it really easy to use. Best of all when I loaded up the example code both sets of motors can be seen to move forwards and backwards!

As, hopefully, this will be the last motor driver board I solder up for this robot I thought I'd detail how I went about putting it together, in case anyone else finds it useful reading.

First I took all the components I was planning on soldering to the board and checked that they fitted correctly (This particular board comes with multiple ways of being assembled).

Next I started adding the Arduino shield connectors. First I insert the connector and add solder to one pin,  holding it in place. I then check the position of the connector and, if I'm not happy with it, heat up the solder and adjust the fitting. Its important to get everything lined up correctly, otherwise the shield won't plug into the Arduino. Once I was happy I then proceeded to apply solder to the rest of the pins.

With one connector fixed into place I worked my way around the rest of the board, periodically cleaning and re-tinning my soldering iron to ensure there weren't any build ups of solder, and to try and ensure the new solder melted quickly, as the longer the soldering iron touches the pins, the more heat is transferred into the board, potentially damaging it.

All the shield connectors and jumper connected.

Next was attaching the battery and motor leads. I had already cut these off from the old motor driver and tinned the ends. I was expecting these to go fairly smoothly, but for some reason the solder just didn't want to co-operate, refusing to stick to the board or the wires.. just blobbing up on the end of the soldering iron. Even using a flux pen didn't seem to help much.After a little perseverance I got the wires connected, but without the nice smooth looking solder connection I had managed on the previous board.

Looks a little messy,  but does the job.

The way this shield sits on top of the Arduino means that the motor/battery connections are dangerously close to the ICSP pins. So, to reduce the chance of contact if the robot went over any bumps, I used a glue gun to cover the exposed connectors.

Then it was a case of plugging it into the Arduino and checking that everything was working correctly. I did run into a problem with one of the jumper pins not being connected correctly, but a quick re-heat with the soldering iron got it sorted.

Next job is to install this motor driver onto my robot, but not in the hap-hazarded way I did last time to test it worked, but in a more permanent way.

Leo

All aboard! - First controlled run

With the distraction of the Sense HAT put to one side I've returned focus to getting OptimusPi moving in a controlled manner. I've previously done a quick test of the motors with a PS3 controller physically connected to the Raspberry Pi, but of course that limits how far the robot can actually move, so its time to switch over to wireless.

As I'm trying to avoid having a USB Hub on the robot, trying to keep things compact, I'm using a 'Lindy USB Bluetooth & HS WLAN 11n Combo Adapter' that allows the single USB port on the Raspberry Pi A+ to provided both wireless and Bluetooth connectivity. Then its just a case of following the setup guide from an old MagPi article, strapping everything to the chassis and connecting the power.

To keep on top of these various steps I also made sure to update the README with install instructions, just in case I get a corrupted SD card and need to reinstall from scratch.

Its a bit messy, but it works.

With everything powered up its just a case of SSHing into the Raspberry Pi, running the MotorTest script from earlier and going for a little drive!

So a successful first test drive with only 2 real problems. Firstly I've still not fixed in the PVC pipes, so they move when turning, and secondly the motor driver doesn't go backwards on one side, making the turns a little cumbersome. I've checked the software, read the datasheet, examined the hardware and replaced the motor driver but with no improvement. Reading around it seems some of the more cheaply produced versions of this motor board can be unreliable, so to avoid wasting too much more time I've now ordered a completely different motor driver.

Leo

We interrupt this blog - Sense HAT released

This week I've been slightly distracted by the launch of the RaspberryPi Sense HAT. This little board contains a pressure, humidity, temperature and 9 DoF Gyroscope/accelerometer combo, as well as a 8x8 LED matrix and a mini joystick. What does this mean for my PiWars entry? Well it means I don't have to solder up the separate sensors and lights I was planning on putting on my robot, and can instead just drop on the Sense HAT itself, which makes things considerable easier. Of course the downside is that its just as easy for any of the other competitors to add a Sense HAT, which means I need to find more to add for the 'most featured robot' challenge!

Everything on the left is included in the board on the right.

Another bonus is that the Sense HAT comes with libraries to access all the sensors easily, and a quick python script quickly gets information out and display it on the LED matrix. So it only took a few minutes to get a python script running to output information from the cursor keys (It took longer to get the video!).In theory the joystick should trigger it as well, but I haven't gotten that quite working yet.

Of course the plan this year is to have a C/C++ based set of code, instead of a python script, so still need to investigate how to get at the information a bit more directly. But that's a future issue, for now its back to getting the robot itself driving around..

Leo

Coding, Coding, Coding - The Software

Let the coding commence!

With the motor controller wired up and (mostly) working its time to start on the software, as without that the robot isn't going to be moving far, and to allow you to follow on with development I've created a new Git repository at https://github.com/LeoWhite/OptimusPi

The motor driver haphazardly connected to the chassis.

To being with I've just taken some of the source code I used last year (The Arduino source and a cut down python test script), cut out the unused functionality and updated it to support the 'Monster Moto Shield' instead of the T'Rex controller. With a bit of fiddling I'm now able to drive the motors using a PS3 controller.

Obviously this is just an initial test and its going to take a lot more work to get the robot driving around autonomously (I can already see the watchdog firing on the Arduino.. an issue I had last year too), but its a good starting point!

Leo

New motor controller

The parts have arrived for the primary motor controller. I've gone with a 'Monster Moto Shield' (which has dual VNH2SP30 chips on it) and, for ease of integration, an AdaFruit Metro Arduino board to plug it into.This board allows a current draw of upto 30A which, in theory, is way more than I actually need. Although as I'm pretty certain I burnt out a motor board last year when the wheels locked up I'm happy to have the extra over head.

The shield + arduino is considerably smaller than the motor driver I've been testing with, being a little smaller than the Raspberry Pi A+ itself.  I still need to work out where to mount it... I could have it above/below the Raspberry Pi, or mounted on the bottom of the chassis...

Ideally I'd have preferred a self contained motor board that supported i2c, but struggled to find one that could handle the high current required. The PicoBorg reverse (Which I already have) is rated a little too low for safety (5A when the motors stall at 6.5A) and the Diablo board would be overkill (and is out of stock). Hopefully this Arduino board won't keep locking up in the i2c code like the one I used last year did, which left  my robot driving around in a circle in the middle of the obstacle course challenge until the hardware watchdog kicked in!

Next steps will be mounting the new motor driver and then starting on the software.

Leo

Moving on out - Driving the motors

With the basic chassis complete-ish the next task was to get it moving around so I can see if it actually works. The first step was to wire up the motors themselves, and for this I used a 15A rated figure 8 cable. Whilst this is overkill for the motors themselves (they have a 6.5A stall current) I would be connecting two motors on each side of the motor driver board, and its easier to use the same cable throughout instead of mixing and matching. As the back of the motors get a little close together I used a couple of pieces of heat shrink wrapping to cover the contacts to prevent shorts.

As this was only a test, instead of the final design, I left the leads quite long on the motors so I could cut them to fit later on. This should be easier than trying to remove the wires and solder on new ones in the future!

Having gotten rid of the large all-terrain tyres I was able extend the length of the pipes I was using to hold the motors, drilling a hole in the middle for the cables to come out of. To ensure the motors fitted better this time around I wrapped a strip of rubber around each one. This, combined with putting 4 notches in the end of the pipe instead of 2, gave a much firmer fit once the clamps were tightened.

For this test I laid the rest of the components out in a line. The motor driver on the front, Raspberry Pi in the middle and the battery on the end. The motor driver was one I got last year off ebay and, whilst a little large, is the only one I currently have that is rated for the motors. The battery and UBEC I'm re-using from one of my BigTraks.

Using a couple of terminal blocks, and several cable ties, I was able to wire everything up. I did start looking at installing software and a python script on the Raspberry Pi to do some basic controls, but ended up connecting the motor driver directly to the 5V power rail, which should in theory cause it to drive forwards and full speed.

With everything connected up, and checked several times, I powered up the Raspberry Pi and (after making sure the wheels weren't touching the ground) connected up  the motor driver board. At this point the left hand set of motors burst into life, but the right hand side didn't move. I'd already checked that all four motors worked before installing them, so I knew it wasn't that, so I spent a bit of time checking connections but was unable to spot any issues, meaning its probable the motor driver at fault.

As it was getting late I decided to leave things as they were for now and see how things looked driving around. I was happy to see that the motors were being held in place and the pipe itself didn't end up turning. With the unbalanced power (only the left motors working) the pipes themselves did get pushed to one side, but I was pretty much expecting that to happen. A holding screw would deal with that, but there seemed little pointing adding it to this prototype.

So overall it was a successful run, with several known limitations. I've got a slightly more compact (and powerful) motor driver turning up this week, and once that's here I can start thinking about the software side of things.

As for the hardware, I still need to work out the best way of setting things up as there needs to be a clear space at the front for adding sensors and other challenge related components. My initial scribblings have the Raspberry Pi being raised and the battery installed underneath it.  I'm also considering mounting the motor driver and battery underneath, but I need to ensure I have sufficient ground clearance for the obstacle course... So still plenty of things to try out and test before finalizing the chassis design.

Leo