Getting straight to the point

I have now started looking to code up some of the logic for the automated challenges. The first one I’m aiming for is Blast Off, the straight (ish) line challenge. For which I’ve mocked up a (colour reversed) course using some lining paper and black electrical tape.

Last year I attempted this with multiple HC-SR04 sensors. But we had a bit of a wobble on the first run, crashed and broke the connections enough to just crash the code. So must aim to write fail safe code this year!

For 2019 we’re looking to learn how to use a Pixy2 for the challenge. The initial coding attempts were a bit shaky but by the end of the evening I managed the run in the video above. It was a bit of a fluke, hence not expecting the robot to turn at the end.

But this is all good encouragement that things are heading in the right direction especially as there’s only a few weeks to go. Hopefully with some more studying of the vector data that’s coming back I can look to guarantee the turns and ramp the speed up a bit.

Advertisements

Final design getting closer

More work was done today on the design and layout of sensors on our robot. We need to start thinking about a “shell” at some point to try and make things a bit more space like. But that might have to wait whilst there’s a big push on the software side to mean we can at least make an effort on the autonomous side of the challenges.

Seeing some of the other robots being worked on and their designs and custom boards is giving me a bit of a feeling of being an imposter and out of our depth in this world. But we’ll keep pushing on with our basic knowledge and continue learning as we go and see where we get to.

Thanks Santa

An expected donation from Santa has led to an upgrade on the camera front for Diddybot. Now to start working on reading up more on how the Pixy2 works and integrating it into the code.

More pins needed

IMG_5598

Things are moving along although a bit slower than I’d hoped. We’ve now had a bit further redesign, hiding all the batteries on the lower level and having the Pi on top. I also discovered I wanted access to more pins than the Picon Zero was allowing. So we’ve added on a ModMyPi Triple GPIO Expansion Board. I’m sure there might have been other ways to do this, but I was wanting to go simple and quick.

Adding this has allowed us to add on a row of Blinkt! lights (a prize from our first attempt at PiWars last year) which we plan to use for status display (or just to blind the other competitors) and then also next to add on are the VL53L1X time of flight sensors. These also need the use of a TCA9548A I2C Multiplexer so that we can have multiple ones attached even though they all use the same address. At the end of all this I plan to write up a post of parts – although then I might start to realise how much this fun hobby costs.

Then as you can probably tell from that ribbon cable, we want to look at adding on a Pi camera as well (another part of our prize from last year). Although at the moment I have no idea how to code up the use of that, so hopefully Santa will bring me some tips.

Meanwhile, I’ve set the boys the task with coming up with a design for the body. I’m trying to keep them along the theme of space, but they seem more interested in baby sharks at the moment.

Sometimes you just need to sleep

In the last post we noted that we were having controller issues. Most of our time at robot club was spent looking at the basic controller code trying to understand what may be the issue. Deciding that we needed some debugging assistance we put in a print out of what information the robot was receiving from the controller to see if this would point us at anything.

In the way these things go, the addition of this single print statement to write out the joystick position every loop saw the robot suddenly start behaving perfectly. So we removed it again and immediately saw the erratic behaviour again.

So now we have a sleep(0.1) statement in there instead. We’re assuming that we were just confusing things by polling the controller to often, or sending commands to the motor controller board to often. Still now that we’re having a little sleep every so often things are fine.

It just confirms what we’ve all been told, a little bit of sleep really does help you work better!

Making progress: controllers and an access point

We continue to make small steps of progress. The controller is now hooked in to the motor code and we can drive the robot around using it. We’re seeing a few cases where either the commands are getting dropped or stacked up which makes it a bit uncontrollable at times. So those are going to need to be debugged at some point. Not sure if its a controller issue, a code issue or reading around may even just be a power issue. So will have to keep an eye on it and see if we can work out which.

To aid in development we’ve also looked at turning the robot into a wireless access point. This means that now we can ssh into it easily without having to try and connect it to a local wifi or wired network first. This was a lot of trial and error of running through different guides from various websites. The one that appears to have worked for us though isĀ https://knowledgeofthings.com/rpi-access-point-raspbian-stretch/ so big thanks to the author for taking the time to put it together.

It’s Robot Club on Sunday so we’ll get to play a bit more on the obstacles and see how others are doing. Next plans are some work on the chassis and then starting to look at adding sensors and the camera to aid in the autonomous tasks.

Issues and redesigns

buggybot

Unfortunately over the past month we haven’t had much chance to work on the robot. This was doubly frustrating as the chassis we had put together was driving forwards and backwards fine, but it just wouldn’t turn! Whilst this might be ideal for the straight line challenge it wasn’t looking good for our ability to take part in the other challenges.

My limited knowledge of motors and robotics really started to hit home here with nothing obvious jumping out at me. However with some iterative redesigns we started to get something working and I started to realise that it was probably all related to the motors stalling due to the weight distribution and wheel separation putting too much force back on the wheels during the skid steering. Perhaps the fact that every time we tried to turn we started to get multiple wheels spin off and bounce into the distance should have hinted at that.

So now we have the basic design in the picture above. We’ve moved all the weight (mainly the batteries) into the middle area (if you check the earlier image they were at the end). We’ve also moved one set of wheels back a bit to bring them closer together (you can spot the old holes in the image).

This combination of changes now sees our robot spinning around even at reduced power levels to the motors. Although I still need to investigate how to get more power to the motors as although we’re sending 6v into the motor board, we appear to be losing about 1v across the board, so only seeing 5v come out.

But we’re moving forwards (well round and round) which has bounced our spirits that we can do this.

Next is moving from basic keyboard controls to actually hooking up a controller and having a framework for the core code. Then at least we can start to get some driving and obstacle practice in whilst we start to think about the rest of the design and sensors.