Building a robot can be great fun, it’s really rewarding when things go well, but sometimes there are things that can be really difficult. Below, our team share some of their best and worst bits of the project so far:
With our recent office move, we haven’t really had time to install a full blown workshop (which we had at our old site). As a result, any practical work we do in the office has to be done on our desks and cleared away at the end each build, before the next working day. However, through more of the office staff becoming involved in our PiWars entry, we are building a good business case for upper management to see the light and buy us nicer tools and find us a permanent space to undertake more practical engineering projects.
One example was using the 3D printer. We designed some motor brackets for the wheels of the robot and wanted to get some quick prototypes made, so thought we’d use the company’s 3D printer. However, it was just a cheapy one so Alan and I had to spend the best part of 2 days hacking it apart to make it work properly and produce at least a half-decent print! But it was worth it on two fronts; first we validated the design and eventually got some great new wheel motor brackets. Second, upper management saw the effort that went into trying to get the cheap 3D printer to work, and decided to invest in a more robust and reliable machine which should help with future design prototyping – both for PiWars and for future pi-top projects!
I’m still not 100% sure how I ended up making the vlog for the unboxing with Alan, you may have been able to tell that I was less than impressed; I definitely could’ve done with an autocue!
Although I joined the PiWars team late, I’ve been really enjoying working on the machine learning side of coding, so much so that I’ve been trying to shoehorn machine learning into every challenge; I’m not sure the team agrees with me!
It’s been great fun coming up with concepts for the tasks. Determining different approaches, and then deciding on final ideas as a team.
Whether it’s running the setup with motors of with different RPMs, or trying out different motor driver HATs, it’s always great to work together and build cool projects. Really looking forward to seeing how everyone else has approached tackling the same tasks and maps. 🙂
Robotics has been known for creating some pretty cool things, from time to time:
When way back in August Cat mentioned PiWars and the possibility of submitting an application to enter as a team I was thrilled. It was my first month at pi-top and I was still getting to know my new workmates and the amazing Pi community but I thought it was a brilliant idea – building a robot powered by the Raspberry Pi? Coding? Sounds right up our alley.
Fast Forward to seven months later I couldn’t be more glad we made that decision. We’ve been pretty busy here at pi-topHQ over the past months (we launched the fab new pi-top in October, then I got caught up in the Christmas campaign planning and before we realised, it was Bett 2018) but our PiWars weekly meetings and build sessions have always been a good way to evade work for a few and just have fun creating our robot. I’m not the most techy person in the team so there are times that I wish I could help my teammates more. However, I definitely enjoy learning from them and to be honest, sometimes their conversations are quite amusing.
It’s also funny that, without even planning it, we’ve involved the whole of our UK office with the build and testing (annoyingly for some, specially when we decide that it’s a good time to take the robot out for a spin). Our Friday afternoons at the office are way better now that we have our green roboTOP (aka Frankentop) around!
There are nine people on the pi-top PiWars team and it can be a bit of a challenge to ensure that everyone is on the same page, especially with different levels of expertise amongst the group. From my perspective, the building and coding is something that just seems to magically happen, but I’m sure the hardware and software guys and girls have had plenty of challenges along the way. My role seems to mostly be to make sure that everything is running smoothly and that everyone feels part of the team and so far that has gone quite well, but it can be hard work to get updates from the different teams so that we can bring together all the ideas.
One of my favourite things about working on this project has been the bringing together of different teams within the office – we have a big collection of different people from different departments, although I have noticed that nearly all of the pi-topCLASSROOMs dev team seems to have joined our PiWars team! Either way, it’s been great fun to work with people that I wouldn’t normally spend time with during the working day so I’m really grateful to have been part of this project.
Finding an appropriate software language and architecture for our robot has been an agonising and rewarding experience. Python is the natural choice due to the amazing wealth of Raspberry Pi community hardware libraries but the emotional rollercoaster began when we began to compose our while Trues together.
With several web developers in the team, we saw our robot as a server which should communicate with number of interfaces and users. Achieving this interconnected concurrency in Python seemed tricky (ugly). Although the new asyncio library might have proved us wrong we had a favourite hammer up our sleeves: Node.js.
So an architecture emerged: Node in charge, spinning up IO modules and passing messages between them. But at the core of several modules are Python child processes, handling heavy lifting in opencv and precise timing requirements like software PWM.
The biggest problem for me is how many times we’ve reassembled the Frankentop – whether from loose cables or battery packs on fire, it’s great fun but incredibly frustrating. As an engineer, I want things to work properly first time (and I don’t want to have to write blog posts, Cat).
The biggest challenge we’ve faced as a team, in my opinion, has been finding the time to work on the robot. Many different areas need to align in order to work effectively – a functional prototype needs to be assembled in order to test the code, progress needs to be made in order to blog about it, course models need to be built in order to practice – and trying to coordinate 9 people around varied and demanding schedules has been difficult.
In trying to work around this, the tendency is for people to work on parts of the robot independently. While not ideal, this has actually been the biggest highlight for me: we’ve really picked up momentum thanks to the stellar contributions from some of the team members who have taken it into their own hands (and own spare time) to experiment with different parts of the robot; this has made it a lot easier for the team as a whole to come together around a working prototype and codebase and tackle specific tasks, since the “hard part” of getting started has already been done. So shout out to Chris, Angus and Liv for having put together the majority of the Frankentop at this point!