It's not always a software problem

I've been doing some work to try and improve the reliability of the distance sensor on the Hull Pixelbot. Not that it isn't particularly reliable, but I got to worrying about all the interrupts and timers that are going off as it takes its readings. 

I did some tests today and discovered, to my alarm, that the distance reading was being horribly affected when I turned the motors on to move the robot. This was a problem. I spent a lot of time turning on and off different parts of the software, and getting more and more confused. I'd got to the point where just turning on one port seemed to be affecting the signals on another, completely different, port. Ugly.

Then I remembered. This is hardware. Hardware is not like software. It's, well, harder. Weird things happen in hardware. Things that end with comments in the code like "I'm not sure why this statement is here, but if it isn't here the device doesn't work". 

When I turn the motors on, this makes the robot take quite a bit more juice from the power supply. If you're careful with your cash, like me, then you run your robot of the PC USB cable when you can, and keep the batteries disconnected. Which means that when the motors fire up the supply voltage takes a bit of a nose dive. Now, it turns out that my distance sensor is rather sensitive to low supply voltage, so this seems to offset all the readings.

In other words, I could fix my broken program just by turning the power on. 

3D Printing "Snap Off" Components

I'm putting together some Hull Pixelbot kits and one of the components that I need is a set of spacers to separate the circuit boards from the perspex base and top. You can of course buy these, but I'm too mean to do this, and I happen to have a 3D printer that I can play with. 

I wanted to print all the spacers as a single item, so that I don't have to count them into each kit. One way to group a bunch of components together is to print using a "brim". A brim extends around the base of a piece and helps it stick to the printer base. If components are placed close together the brim merges to form a single sheet which holds all the components together. This works well but it can be quite a pain to then peel the brim off the items once they are printed, particularly if the items are small, like the washers above. 

The solution I've come up with is to print a single layer which sticks all the elements together,  followed by another layer on top of that which stiffens the support layer. If you look at the picture above you'll see that the top layer doesn't go all the way up to side of each spacer, there's a tiny gap around each one. This lets you "snap" the spacer out of the base.

One other trick that I'm using with my spacers is to print the first layer of the spacer with a hole which is slightly smaller than the others. This means that the spacer will grip onto a bolt, so that they are a bit easier to fit onto the robot when you are building it. 

Hornsea in the New Year

Way back when we used to go to Hornsea on New Year's Day. We didn't manage it this year, the weather wasn't good enough to tempt us out of the house, but we did go today. Of course I took a few pictures. I took the one above on Hornsea Mere. I love the way that the pier creates a calm region of water on the right of the picture. This might be a nice metaphor for people in these fractious times.

The new Paddington movie is better than Star Wars

Before Christmas we went to see the new Star Wars movie. Lots of bangs, crashes, people turning to the Dark Side (or not - who cares), more bangs, more crashes. The end. It was OK. 

On Wednesday we went to see the new Paddington Bear movie. It was awesome. A tale of a bear always trying to do the right thing, striving to see good in everyone and managing to find it in a variety of beautifully realised situations.

I've got nothing but warm memories of this film. I'm finding it hard to remember much of the Star Wars one. Paddington rules. Go see.

Lora at the c4di Hardware Group

We had a great hardware meetup tonight. I showed off a bit of the latest Hull Pixelbot scripting stuff (once I'd got it to work - note to self - don't turn up with a machine and think you can install the software and it will just work. Doesn't happen). 

Then we talked a bit about Lora (or low powered radio to you). I've blogged a bit about this in the past but now we want to take things a bit further, and get going making Lora stuff. We've got all kinds of plans, none of them involving world domination. At least that's what we're saying for now. 

Anyhoo, expect to hear more about our Lora plans in the not too distant future. It looks like a great technology to get in on the ground floor of. If you fancy getting involved you should come along to our next meetup and utter the magic phrase "I fancy getting involved". You can sign up for the next meetup here

A Dashboard Camera for 10 quid. What could go wrong?

One of my New Years resolutions should have been "I must stop buying cheap and useless gadgets".  But since I haven't made that resolution, and I found myself in the local grocers looking at the bits and bobs on offer, I ended up buying a little dashboard camera for a tenner. 

It comes with a mounting for your windscreen, a power connector and even a little lithium battery so it can be used away from the car (I want to attach it to a Hull Pixelbot). 

It works really well. The camera is reasonable quality, the controls a bit clanky, there's some HF whistle (which I can't hear) when it's switched on. But overall a win. 

Except for one tiny flaw that I've yet to resolve. You need to add an SD card which is used to store the video. When I take the card out of the camera and try to use it in my computer the files on it are not recognised. I hope it isn't using "write only memory" technology. 

Hull Pixelbot Scripting Language lives

One of "Robert's Rules" of programming is that things that sound simple often aren't. And things that sound complicated often aren't. A while back I had an idea for a simple scripting language that could be used to control Hull Pixelbots (or anything else embedded). It sounded simple. It's not.

I've been playing around with the language and I've just about got it going. It's not as simple as I might like, but it does work. The biggest change that I've made from previous versions is to use the "Python" style of code blocks. I did have "endif" keywords to mark the end of conditions but I found these really irritating (I kept missing off the endif and then wondering why the program wouldn't compile). So now you indicate which statements are controlled by a condition (or a loop) by just indenting the statement. Want to see some sample code?

begin
move 100 wait
turn 180 wait
move 100 wiat
end

This program would move the robot forward 100, make it turn 180 degrees and then move back. The wait element means "wait for this move to complete before performing the next statement". If the wait element is omitted the program starts the action and then moves onto the next statement immediately. We can make more interesting behaviours:

begin
forever
    green
    move 100
    if @distance < 100
        red
        turn 90 wait
end

This program makes the robot move forwards. As the robot moves it checks the value returned by the distance sensor . If the program detects an object less than 100 mm away it turns the robot 90 degrees and then continues moving forward. The red and green commands change the colour of the pixel. The indenting above tells you that the red and turn 90 statements are only obeyed if the distance is less than 100. 

The programs are compiled and executed inside the robot. I've written a tiny Python program to send them via the USB port. 

Update: I've made some tiny changes to the way that the wait behaviour works after showing someone the language and realising that it could be better. 

Mario and Rabbids for Nintendo Switch

Another game I've been playing with over the break is Mario and Rabbids on the Nintendo Switch. It's a fun little game that was on offer at a temptingly low price over the Christmas break. I like it because it's turn based. You give your characters their instructions and then watch the action unfold as they get into position and shoot at the enemy. Then the enemy takes their move, and your carefully laid out plans collapse before your eyes. Although that might be just me. 

I really like the way that there's no limit on how long you can spend thinking about what to do next. I'm rubbish at most "shooty" type games because I have a habit of standing and thinking, never a good plan when there are snipers about. But with this game I can spend as long as I like choosing who to send into battle, which of the wonderful weapons to give them and what to make them do when they get there. There seems to be a huge depth to the action too, with stuff laid around the levels that really encourages you to go back and play them again once you've levelled up a bit. 

If you've got a Nintendo Switch you really should get this game I reckon. 

Dark Souls III

Number one son has brought his Playstation 4 Pro along for the Christmas break. And he's bought Dark Souls III

I'm finding it great fun to watch him play it. There's a lot of death involved. Quite a bit of it involves the player. It seems that you learn the right thing to do in every battle by doing the wrong thing first and finding out that it kills you. The graphics are impressive, if a bit murky, and the animations and actions of the different forms of the evil hordes that you need to kill are very well realised. The voice acting of the characters is well done, and the story is suitably preposterous. Worth a look if you've got the patience of the un-dead. 

We didn't playtest this at all

Lovers of games involving strategic play, intense plot and mental strength should look away now. Lovers of idiotic fun though, that's a different matter....

We didn't playtest this at all is daft. It's the kind of game you can win by being the shortest player. Or lose by being eaten by a dragon. Or not touching your nose the right number of times. The games are short, furious and fun. I can't imagine spending an entire evening playing this game, but for a bunch of mad fun before you start playing Coup I reckon it would be hard to beat. 

Idiot ebay buyers

Here's a model for a business. Search ebay for things which appear to be going cheap. Make a stupidly high bid for the cheap item to try and win it at a knock down price. If you win at a low price, pay it. If you win at a high price, delete your username and walk away.

I've had this happen to me before. Up until now the buyers had the "decency" to come up with an excuse for their stupidly high bid before retracting it. This time they just deleted the user. 

It occurs to me that eBay should probably keep track of the postcodes used by buyers and check for large numbers of accounts being registered/deleted at a particular location. This would seem to be a good use of all this "artificial intelligence" that we are always hearing about