M.E.T. 2019

After the Competition

2019-04-10T00:00:00-05:00

The good news is: we at least attempted all challenges and Phantom survived (mostly). The bad news is: we did very badly.

Here is how the “final” version of Phantom, our walker based on poorly understood alien technology, looked like (photos taken after the competition):

Unfortunately, Phantom was far from finished. We had to cut a lot of features that we initially intended to have during the last few months, but that wasn’t enough: we couldn’t even finish the essentials in time. Our goals have proven to be a bit too ambitious, and by spending a lot of time on various details, some of which were probably not essential, we ended up in a situation where everything was half- or almost finished, but nothing ready. (“Second-system effect” maybe?)

This led to last-minute assembly of the “final” version, including late-night re-printing of the chassis the day before to fix some sizing mistake, taking short-cuts where things didn’t quite fit together, like using Blu Tack – with a few minutes left at the end for testing and hacking on the software to at least make the basics work (the latter continuing even during the competition).

We also had a major problem with our choice of motors that only became apparent very late – see the previous post. This meant a lot of time wasted, and at the end we had to fall back to the small micro metal gear motors we used earlier: these had just about enough power to drive reliably, but were very slow. Ideally, you should finalise the mechanical / locomotion / motor control part of the robot first, and build everything higher level or fancier on these already stable foundations. In our case, the seriousness of the lack of precise control at low speeds only became obvious when we tried to implement control for the autonomous challenges – so maybe it’s a chicken and egg problem: you don’t really know if your “foundation” is good enough until you actually use it for real…

Despite all this, the overall journey was great fun, a lot of “crazy” experimenting with a huge amount of completely new things tried and learned – in no small part thanks to the awesome Pi Wars community! And even despite failing in literally every challenge, the final Sunday we’ve been waiting for a long time was amazing and we thoroughly enjoyed it!

And now, here is a summary of how and what we did at each challenge – and most importantly, the lessons learned (or should be learned)!

Pi Noon: The Right Stuff

We got “destroyed” in the first few minutes: our opponent, a much heavier robot, hit us from the left and a critical part of a single 3D-printed gearbox/motor assembly that connects the big gearbox with the motor, snapped. This was a fatal blow: with a broken gearbox, we couldn’t move and there was a risk of dropping out of the rest of the competitions for the day.

It wasn’t our opponent’s fault though: Pi Noon is supposed to be “non-destructive” but even if you’re not doing it intentionally, it’s inherently aggressive in the sense that you do need to drive at your opponent, and collisions are inevitable. If a heavy robot with a lot of motor power happens to hit sideways a weak or unprotected spot, damage is inevitable.

We didn’t have any spare parts, but fortunately we did bring lots of sticky tape, even two different kinds! So we managed to fix the broken gearbox. There was nothing else apart from the tape, nothing rigid to support the weight, and to prevent the left side from collapsing. It was a little bit wobbly, but amazingly, the tape held throughout the whole day!

Analysis

The main issue is that the part that snapped is cleary too weak: those two horizontal bits were supporting the whole weight of the robot and were too thin.

Phantom was not designed or even tested for Pi Noon, so the danger from this kind of collision wasn’t even considered.
The gearbox/motor assembly was actually a weaker, second version: the original design was for bigger motors, with wider and thicker struts. This second version was “Plan B”, designed hastily, “merging” parts of the original (holding a round motor) with a rectangluar holder for the small motors we had to revert to.
We should have done some stress-testing for the critical 3D-printed parts: nothing fancy, just testing it by hand to see how easy it is to break it would have helped!
We were planning to print and bring a spare gearbox complete with legs, just in case something breaks or fails during the day. Due to lack of time, this didn’t happen.
Sticky tape can be stronger than 3D-printed plastic!

Spirit of Curiosity

This was quite a straightforward challenge – you pick up a sample and bring it back, right? The reality is, getting over the crater in the middle was very dangerous as we weren’t sure if Phantom would survive a fall onto its back. The only other option was to go around which was very time-consuming and also the robot only just fitted into the canyon around the large “hill”, and so it was difficult to maneuver through it. The small bumps and uneven details were also a problem as the robot got stuck on them on more than one occasion. We still managed to bring back one piece of sample though!

Analysis

In theory, legs should be perfect for this terrain. Unfortunately, our motors didn’t have enough power. The legs were also quite small, as we wanted to keep the robot body as small as possible. Phantom was also very slow: even without getting stuck, we wouldn’t have been able to do many more round-trips in the allowed time.

We really need motors that are both more powerful and faster.
Making the legs a little bit bigger and/or changing the stride to lift the legs higher would definitely help here to avoid getting stuck.
Another problem (which we luckily didn’t encounter) was the chance of the sample falling out and having to go back to the pile again. To avoid this the robot should be quite stable and maybe it would have been nice to have added some sort of suspension.

The Canyons of Mars

We didn’t have high hopes for this challenge. The “proper” code was not ready and all the testing was done the night before, for about 5 minutes. So we just relied on a very simple idea that we were experimenting with: a simple, generic “behaviour” to keep going forward and avoid obstacles – just based on distance sensors, without knowing anything about the layout of the maze, or taking into account orientation or anything else.

The code is literally just a few lines. Here it is:

dist_sensor_angles = [-np.pi/2, -np.pi/4, 0, np.pi/4, np.pi/2]

[…]

def run_canyons(state):
    dists = state.get('dist', None)
    if not dists:
        return                                           # Return if distances not available yet
    state['speed'] = 7                                   # Drive at constant speed, forward (max. is 10)
    dist_vectors = [(dists[0], dist_sensor_angles[0]),   # Get the distances as vectors,
                    (dists[1], dist_sensor_angles[1]),   #   measured at ±90° (sides) and ±45° (front)
                    (dists[3], dist_sensor_angles[3]),   #   (and ignore the front sensor at 0°)
                    (dists[4], dist_sensor_angles[4])]
    dist_sum = sum_vectors(dist_vectors)                 # Add up the above vectors
    state['dist_sum'] = dist_sum
    state['dir'] = np.rad2deg(dist_sum[1]) * 1.8         # Turn towards dist_sum: the longest opening

This is how it looks in simulation, using the same exact code as above (the yellow “beam” is the dist_sum vector):

(One interesting thing learned from the simulation: at first, we tried it with only the three sensors at the front – it was much harder, almost impossible to navigate through without hitting a wall or turning back. But adding the left and right 90° sensors made a very big improvement!)

We didn’t win with this of course, but it worked surprisingly well: in our first try, we only needed one “rescue”, near the top left corner, and after that, our robot continued to the exit. On the second try, somewhere near the second bend, it turned back and found its way back to the entrance – taking a shortcut, which is completely reasonable if your “goal” is to escape, rather than to go through the maze!

Analysis

This “success” has proven that it was worth it to develop all the simulation tools, and that sometimes a very simple approach can work too.
With some more tweaks (e.g. something like disallowing 360° turns or backing off when getting too close to a wall and trying again), and a bit more real-life testing, this could have been made much more robust.
And of course: Phantom was slow – we need more speed!

Space Invaders

No surprises here. The shooter attachment simply didn’t make it: we had an idea, but this was one of the things that were completely left out at the end, due to lack of time. So we simply tried to nudge the balls but Phantom was too slow. The tiny motors we ended up using were just enough to slowly and carefully roll the balls over the white line, but not much further.

The Apollo 13 Obstacle Course

This challenge was fairly straightforward apart from the treadmill which was very frightening. We ended up skipping it because Phantom didn’t have any thing protecting it should it fall over and flip. The rest of the course wasn’t too difficult – the problem was time. The robot was simply very slow and so we only managed to do one lap and were over the time limit.

Analysis

The Oyumaru thermo plastic ’feet’ (a silicone-like material that melts easily in hot water and can then be formed by hand) were really useful in this challenge for gripping onto slopes (and just generally not falling over). The feet worked very well and didn’t come off (unlike last year’s wheels).
There were no problems with controllability. But we had an idea that we didn’t get around to implement: “absolute” directions for remote control: by using the compass (9DoF sensor) the joystick could be used to point to absolute directions: so instead of turning left relative to the current heading of the robot, you could point “left” to the “left” of the course. So it wouldn’t matter where you stand – as it’s quite difficult to move around the course and adjust your sense of direction when standing behind or in front of the robot.
We really didn’t have any practice driving before – even if the robot isn’t particularly fast, this would have helped, and some testing with any kind of mock course would have made us more confident!
We need more speed…

The Hubble Telescope Nebula Challenge

This was a perfect example of trying to do a bit of everything but finishing nothing: last year we didn’t attempt this challenge at all. This time, we spent quite a lot of time on perfecting the colour calibration, developing the tools for it, etc. The code was almost ready, the colour recognition worked perfectly, but the whole thing was left unfinished at the end, because of all the other tasks that seemed more critical, like fixing fundamental motor control problems.

So at the end we just attempted to use the “easy” method of trying to visit all corners, only using distances from walls (ToF sensors) and orientation (9DoF sensor) without using the camera at all. The code was put together in the pit room, with no real-world testing. It could have worked, but unfortunately it didn’t: some parameters (speed, minimum corner distances) were not set correctly, so Phantom ended up wandering around the course, looking very confused.

Analysis

Better prioritisation earlier could have helped: maybe giving up preparing for one of the simpler challenges completely, we could have saved some time to finish the work for this and at least have a good chance of doing this one correctly.
Brian Corteil’s Robot Club at the Cambridge Makespace was a great opportunity to test things in the real courses, under the same conditions as at the competition: but because we were always behind schedule, we mostly missed this!

Blast Off: the Straight-ish Line Speed Test

This is really the easiest of the autonomous challenges: as long as you have reliable sensors, there shouldn’t be a problem… We were relying on our ToF distance sensors and an even simpler algorithm than for Canyons of Mars. Again, we didn’t do much testing and wasn’t expecting to be fast, but maybe with some oscillations between the walls this should have worked just fine.

Unfortunately, one of the many leg joints on the right got stuck a little, so the right side could barely move. This resulted in the robot turning right in the beginning, and hitting the wall. The code was just pushing the motor to maximum power, trying to reach the set speed, but of course it wasn’t prepared for this fault. (Generally, in this case the right thing would be to reduce power to the other side to match the side that’s blocked, and keep going in the desired direction, just much slower.)

Analysis

It took a long time and a lot of experimenting to design the joints. Some of the challenges were: keeping the size small, ensuring the joints can rotate smoothly, but still making the joints as rigid as possible, reducing sideways motion to avoid too much wobble. The final design used M2 screws covered with PTFE tubing inside the joints, secured at the end with lock nuts press-fitted into the plastic parts (and with also some thread locker fluid). This seemed to work really well, and we didn’t see much of this issue of getting stuck before. However:

Assembling the legs was quite a long process and required manually cutting the PTFE tubes to exact sizes, and each screw had to be tightened “just right”. After assembly it was difficult to tell whether something was too tight or too loose, without actually trying to drive the robot and looking at the movement and checking the motor power for each side to see any differences.
The final version of the gearboxes and legs were assembled the day before, so these didn’t have much testing. It’s really odd that we only encountered this problem in the last challenge in probably the easiest situation and haven’t seen any issues before during the whole day! But this proves the unreliability of the current design / assembly process.
We need to improve the design of the joints to ensure we have smooth movement, without relying on manual adjustments. Maybe switching to ball bearings – at least on some of the joints – would help, and would also reduce sideways movement (and wobble).
The failure to drive straight also highlighted an issue with the software: even if it doesn’t have to be complicated, all software driving the robot should be much more robust to be able to deal with failures or degraded functionality: this probably needs a different mindset, to consider every possibility, all the what ifs and to fill in all those possible else if branches!

There is clearly a lot to keep us busy to fix all the problems we know of and finish everything properly for next time – the question is: will we do it or will we jump on to the next crazy idea and start from scratch again…?

Motor Control Problems

2019-03-12T00:00:00-05:00

In Pi Wars, there are a lot of puzzles and problems to solve. Some are hard, some are easier, but they are all fun, an opportunity to learn, experiment, do something crazy – that’s the whole point! But there is always one (or two!) completely new problem that turns up totally unexpected, usually at the worst possible time, and messes up all your plans. The famous unknown unknowns… These are usually not much fun.

Looks like we’ve run into one of these again.

When we started experimenting with our first prototype, we used small N20 micro metal gear motors. They were slow, but had enough power to drive the small prototype. The movement looked good, including the ability to turn around in place: the legs worked as expected – a little bit wobbly maybe, but nothing too bad.

Then we switched to bigger, more powerful, 600RPM motors for Phantom (the “real” robot): the goal was to make it run much faster, while still having enough torque at low speed. This was never tested properly, but everything seemed to be fine. Controlling the motors manually at low speed was harder: they need a “kick” to start, then you need to cut back the power to keep them going slower. So Phantom always appeared to be too excited or nervous, moving a bit wildly. The idea was to add speed sensors and a PID loop to control the speed, and we assumed this would “just work” and we’d get the best of both worlds: precise (good enough) control at low speeds, but also not going embarrassingly slowly in the Blast Off challenge.

After a lot of hard work adding the speed sensors and implementing the PID control, adding a new GUI, etc. the unexpected problem appeared: it was simply impossible to tune the PID parameters to get reasonable control! Controlling the speed on a “test bench” was OK: after some tuning we could see on the graph the motor power jumping up, followed by the the “measured RPM” value rising, and after just a bit of oscillation, nicely following the set speed. Adding some extra friction made the power rise again, while the measured RPM was still following the set value.

On the ground it looked worse: starting to move in a straight line at low speed is not perfect, but at least it steadies after a few seconds.

Here is how a similar straight line start looks like on the graph: Some oscillations at the beginning, but not too bad – still, a bit slow to start in reality. Green: set RPM (constant 120), yellow: measured RPM, red: motor power.

Turning in place slowly is really bad though. There is probably too much slippage and sudden changes as legs get some traction, then slip or get blocked a bit, then move freely again… The motors don’t seem to have enough torque at low speed to keep moving, so the PID ends up driving the power up and down. The end result is that we can actually turn – much better than trying the same by manually controlling power – but the movement is very jerky.

Again, a similar turn on the graph: lots of oscillations (the compass in the lower right corner also shows how uneven the movement is). Also, there is a very clear difference between left (outer) and right (inner) legs.

It’s not clear how to fix this… There isn’t enough time to find better motors. One option is to just accept this and stop trying to go slowly, just keep running and stopping. But that’s a risky strategy. We can try changing the gear ratio in our “gearbox”, but there really isn’t much room for making big changes – not without a major redesign.

By comparison, here is how the old prototype behaves with the micro metal gear motors (just directly connected to power, no control):

Looks much nicer! So another option could be to ditch the new fast motors, and go back to these tiny ones, hoping they will be enough for a bigger robot. But then it means this is about our top speed (the only speed really – it’s either going slow, or not at all). Our third option is a crazy idea, but that’s still a secret…

Speed Sensors and PCBs

2019-03-06T00:00:00-06:00

Among the many things we wanted to improve in our robot design since last year, these two are probably the most important:

Add “proper” speed control: don’t just control motor power and assume the resulting speed will always be proportional. With speed sensors and a feedback loop to adjust the power continuously, we can make the motors actually run at a given speed. This should lead to more precise and easier control (both manual and autonomous), being able to go slower even if the motors don’t have a lot of torque, going uphill or downhill at a constant speed, etc.
Make better and more integrated circuit boards: last year’s robot used out-of-the box modules and chunks of perfboards and bundles of wires with bulky connectors to connect them all. Replacing at least some of these with “real” custom PCBs not only would make it much more beautiful, but should also make everything smaller – which is especially important now that we have more components.

IR Sensors to Measure Speed

We are using a reflective infrared sensor (ITR8307) that is looking at an encoder disc with black and white stripes, inside the gearbox. The encoder disc is just a piece of paper glued to the center gear driven by the motor. An improvised hole provides a window for the sensor to peek inside. If we measure how long it takes for one stripe to pass in front of the sensor, we can calculate speed (RPM). Knowing the actual speed can enable better control of the motors and also to implement dead reckoning. We are only detecting speed, without direction, to keep things simple. (We want to avoid sudden changes in direction anyway, and the motors are not that fast, so assuming we’re always going the correct way may be safe.)

The initial testing on a breadboard looked promising. (Who said that a breadboard makes it quick and easy to connecting things?! It’s a mess!)

But it became obvious that the raw input from the sensor is very noisy and that the sensor needs to be very close to the surface of the disc to get reliable results. The main reason for this is that we’re treating the signal as digital input and want to only see either black or white – but the sensor doesn’t quite work like that: the voltage for a “high” signal obviously depends on the amount of light reflected, which is affected by the distance.

One solution might be to read the voltage as an analog value and do thresholding in software. This method is probably more useful for things like line followers. What we would prefer is a hardware solution that turns the noisy analog singal into a clean digital one, which can easily be read by a microcontroller with an external interrupt.

Some more research and experimenting resulted in a circuit which uses a comparator (LM339) with feedback. This produces a nice “black and white” digital output. A very good explanation of the basics can be found in this blog.

Putting this circuit aside for now, let’s have a look at how the “final” version of the sensors look like:

The sensors are mounted on small PCBs with a couple of resistors. The M.E.T. lab has a sophisticated process to make these, using the well-known DIY toner-transfer and vinegar-based etching methods:

Print the traces (mirrored) with a laser printer on a backing sheet for self-adhesive labels.
With a hot iron, transfer this image to the copper surface of the PCB (temperature and pressure is precisely controlled: just press it hard and remove it before things start to burn).
Pour some water into a small plastic container and add some acetic acid, rocket fuel (hydrogen peroxide) and table salt (using a very exact and secret ratio).
Watch it bubbling and add more salt as needed.
Take it out before all the copper disappears.

This process is not always entirely reliable, but this time we were lucky and got a very nice result. (It looks a bit messy on the third image, but this is only because of the uneven surface of the manually tinned traces and the less than ideal lighting. The copper traces are actually perfect.)

Controlling Motor Power

To control motor power, we need two things: something to generate a PWM signal and a motor driver that uses that signal to switch the higher current/voltage for the motors.

The Pi can generate PWM so we could use that directly, but we are using a microcontroller for all the low-level real-time tasks. The PWM output will also depend on the continuous speed measurements, which are especially time-critical, so it makes sense to do both on a microcontroller, leaving only the high-level, non-real time control logic to the Pi.

Last year we had to control four DC motors and five servos, and used an ATmega328 microcontroller, so the number of pins and available PWM outputs were a bit limited. This is why we added another component, a PCA9685 breakout board (a dedicated I²C 16-channel PWM controller). For motor drivers, we used two DRV8833 2-channel motor driver boards. The assembly of all these was the ACF-MAS (Actuator Controller For Motors And Servos). It worked great, it was really easy to use, but it was all a bit bulky.

This year we only have two DC motors so far: these can be controlled by only two PWM channels, so this doesn’t really require a dedicated component. Still, it seems like a good idea to use a proven solution with a lot of room for adding more motors (we have a few secret plans…) – and we always need a bit of over-engineering!

Introducing MOC-SSIU – the MOtor Control and Speed Signal Integrator Unit:

a PCA9685 I²C 16-channel PWM controller chip
three 2-channel DRV8833 motor controller boards
an LM339 comparator to handle speed sensor signals
connectors for up to six DC motors (and their corresponding sensors)
a connector to the microcontroller for I²C and sensor output (a 1.25mm pitch JST SMD connector that looks much better than the usual big pin headers and Dupont connectors)
power connector pins at the bottom (this will sit on top of P-CAMS-2, the power board)
some “spare” connectors and extra pins for any future ad-hoc extensions, just in case
all this on a shiny new “professional” PCB!

The Eagle files for this – and also for the IR sensor boards – can be found in our GitLab repo.

We didn’t trust our own PCB-making process with this, so we ordered the boards (minimum order is five, so we have plenty of spares…) from JLCPCB – and they turned out perfect!

Soldering the SMD components wasn’t too hard, although that PCA9685 chip is tiny! But solder paste (or surface tension?) is magical!

After populating one half of the new board, here is how the first test looked like. Unfortunately this meant disassembling almost everything. The “main” board also needs some rewiring to be able to connect it, we need to find a way to properly attach the sensors (probably printing a new cover for the gearboxes), and most importantly, the code on the microcontroller needs to be updated to actually implement speed control! But more on all this in another post…

Remote Control

2019-01-28T00:00:00-06:00

Finally, an update with some walking, running and spinning! We have a long way to go, but at least we have basic remote control working.

From Joystick to Motors

Our robot uses a very alien mechanism to move but it has simple differential steering: one motor on each side drives the legs forwards or backwards, so the robot turns by applying more or less torque on one side – and it can also turn in place by running the motors in opposite directions. This should be straightforward to control with a game controller joystick. But how does this actually work?

We don’t have encoders in the motors yet, so we can’t measure and control speed, all we can do for now is simply vary the motor power (PWM). The game controller gives us the position of the joystick as (x,y) coordinates within [–1, 1]. We need to somehow translate this to motor power (let’s say between –10 and 10) to be applied to left and right respectively.

Some examples: driving full speed forwards – and turning right half speed (only the left motor is moving):

…and going backwards full speed while turning slightly left – and finally, turning right in place, full speed:

There are simple methods to do this directly and to make the joystick control feel “natural”, like this example for the approxeng.input library. However, when the human driver is replaced by a program to drive the robot autonomously, we don’t want to deal with joystick coordinates. It would be much more natural to make the program produce some desired speed and turn direction values instead. So we’ve added this intermediate representation too. Instead of going from joystick to motors directly, we first interpret the joystick input as speed and direction, and then convert that to motor speeds: (x, y) → (speed, direction) → (left, right).

For the first step, we consider (x, y) as a vector, take its length as speed and its angle as turn direction. Pointing upwards is 0°, maximum turn left and right is –90° and 90°. If the vector points down, we negate the speed.

Using the same examples as above, this is what we want:

There is one annoying problem with the joystick input however: the joystick actually moves inside a square, not a circle! So moving diagonally we’d get vectors longer than 1 – and different speeds depending on the angle, which is bad. We need to map square coordinates to a circle with this formula:

x → x * sqrt(1.0 - y * y / 2.0)
y → y * sqrt(1.0 - x * x / 2.0)

(For more background and explanation, see this question on Stack Overflow.)

So the next step is to convert the corrected (x,y) from above to (speed,dir) – where speed is in [-10,10] and angle in [-90,90]:

if x == 0 and y == 0:
    return (0, 0)
else:
    (speed, dir) = cart2pol((x, -y))  # cart2pol: convert Cartesian to polar
    dir = np.rad2deg(dir) + 90        # np.rad2deg: convert radians to degrees
    if dir > 90:
        dir = dir - 180
        speed = -speed
    elif dir < -90:
        speed = -speed
    return (int(round(speed * 10)), int(round(dir)))

Finally, to get left and right motor power from (speed, dir): we start by setting the desired speed to both motors, then reduce one side based on the turn angle:

left = float(speed)
right = float(speed)
range = speed * 2.0
diff = (float(dir)/0.9) * (range/100.0)
if dir < 0:
    left = left + diff
else:
    right = right - diff
return (round(left), round(right))

The final result:

The complete code (and some more) for the above calculations can be found here: gitlab.com/marsextraterrestrials/control_logic

New Motors, New Legs, New Everything!

2019-01-19T00:00:00-06:00

Here is the next stage in the evolution of our alien robot:

New legs and gearboxes

After an unreasonably long time spent on the design and a lot of experimentation on linkages, we’ve finally made our own leg mechanism. It uses the Klann linkage. Observing how our original toy kit based prototype worked (uses the same mechanism) and especially the resources on the DIY Walkers website were an enormous help.

A byproduct of all this work is “morescad”, a collection of some OpenSCAD utilities, including a module to help making linkages like this.

The total number of parts for the two gearboxes and the eight legs:

50 individual 3D-printed parts
58 screws
2 axle sleeves (to connect the motor to the center gear)
4 hexagonal axles (for the two crank gears)
4 ball bearings

The joints have press-fit self locking nuts and M2 screws, covered with small PTFE tubes (the kind used for 3D printer extruders) to reduce friction. The crank joints (blue bits above/below the gears on the picture) have a hole to insert a nut to hold a set screw connecting to the hexagonal shaft. We also use Loctite threadlocker glue on some of the screws – thanks to Brian C. for the suggestion! (We hope this will prevent us from losing legs like we did with wheels last year due to connections becoming loose.) The two crank gears are connected to the bottom part of the gearbox with ball bearings (transparent gray disc on the picture).

The feet are not finished yet: we need to find something better than the rubber grommets added temporarily for now.

Motors

The new motors are 6V “600RPM Mini Metal Gearbox” motors from Ebay, hopefully with a good balance between speed and torque. They are much bigger than the N20 “Micro Metal Gearbox” ones we used earlier and last year. They are not very powerful, but the aim is to keep everything as small and light as possible. The stall current we measured was about 1.5A, and moving the legs freely takes about 2-300mA, so hopefully the tiny DRV8833 motor driver board (same as we used last year) will be able to handle this.

P-CAMS-2 Rev. 2

P-CAMS-2 (Power Conversion And Management System 2) has also been updated: the previous version used a XL6009 buck-boost module, but some testing with the new motors has shown that it’s performance is not quite like as advertised: its max. input current is supposed to be 3A, but set to 6V output with ~8V input, it shuts down immediately if the load reaches 1A at the output. This could be due to some obviously missing components on the board…

So this has now been replaced by an XL4015 buck converter module, that’s slightly more reliable: when stalling a motor and reaching 1.5A (wires getting hot), its output drops to about 5V but it doesn’t shut down. This should be good enough…

Another update is the addition of an AMS1117 3.3V LDO – so that we won’t need to use the Pi’s or the microcontroller’s built-in 3.3V regulator to power all the sensors and additional electronics.

New motor/sensor control board

This is another new part: a microcontroller board to control the motors and read the distance sensors. Previously we used a PCA9685 board to generate PWM, but this new board will probably replace that and will take care of controlling all DC motors and servos and will also handle the distance sensors. The board is a “Blue Pill” with an STM32F103C8 microcontroller – but more on all this later, in another post!

Frame and sensors

So far we don’t have a complete body for the robot, only a very simple frame to hold the two gearboxes together and to support the various PCBs. This new frame and temporary layout should be enough to test all the components, both the existing ones and some new we’re planning to add later, and to refine movement and control. The ToF distance sensor array at the front is “borrowed” from our previous robot.

But can it walk…? Or run…? Find out in the next post!

Power

2018-11-19T00:00:00-06:00

PM-2 and P-CAMS-2

In our previous robot, in the 2018 Pi Wars, we used separate batteries for the electronics (one 18650 with a boost converter) and the motors (two 18650s in series with a buck converter). This was an easy and reliable solution to avoid any interference from electrical noise generated by DC motors. But it’s not very efficient: the batteries will not discharge at the same rate – and just two would probably provide enough total capacity anyway. This time we want to reduce the weight and also save some space. So here are the second versions of our modules:

PM-2 (Power Module 2) is essentially a battery holder for two 18650 batteries in series with a protection circuit.

P-CAMS-2 (Power Conversion And Management System 2) consists of two DC converters: one to provide 5V for the electronics, and another to give 6V to DC motors and servos. It also has a voltage divider to provide a usable input for battery voltage monitoring. The circuit is very simple:

Motor Noise!

After making a prototype of P-CAMS-2 on a perfboard, a quick test showed that everything worked fine: Pi Zero running, motors moving. For PWM, we’re using a PCA9685 I²C module: this can control up to 16 motors or servos. It can only use a single frequency, so we’re using 60Hz, as the servos can’t really use something much higher, but this has worked well enough for the DC motors too.

Turning the motors full on and off, driving forwards and backwards was OK. But when we tried varying the speed, I²C suddenly started to fail: I/O errors after a few seconds, all the time. We did have 100n capacitors across the motor terminals, and also bigger electrolytics before each DC converter as buffers, but this was clearly not enough!

Apollo 11 could land on the Moon, despite a hardware problem that caused some scary 1201 and 1202 alarms. But instead of crashing, the software recovered, letting the humans ignore the errors and just carry on!

So there is nothing to worry about, we can fix this in software, like this:

while True:
    try:
        # ...Read inputs etc., then drive: set pwm via I2C...
    except OSError:
        # Don't panic, it's only an error...
        # Just ignore and continue, but keep a count so that we can display this 
        # on some fancy control panel later or maybe even plot a chart...
        err_count = err_count + 1

But maybe there is a better solution… Getting lots of errors in a reproducible way now is actually a great opportunity! It means we can investigate the cause, try to change things one by one and see what has an effect on the errors! Much better than having a potential problem lurking somewhere undetected, only to come up later, randomly and unexpectedly!

We experimented with adding capacitors to try and filter out the noise: many variations with different values, caps before or after the DC converters, and/or caps closer to the electronics, more caps near the motor driver, caps on the motor terminals, connected to the motor casing, with or without grounding the casing, etc. And we tested each combination, running the motors on low speed for a few minutes and checking the I²C error rate. Some combinations looked promising at first, but none of them provided any major improvement or pointed towards the right direction.

At the end it looked a bit ridiculous…

We’ve done some research and found quite a lot of useful information:

Finally, thanks to a brilliant suggestion from Brian, we had a winning solution:

Ferrite bead on the power leads to the electronics, right before the connection to the Pi!

Other combinations (adding the ferrite bead before the DC converter or putting it further away from the connection) didn’t help or only slightly reduced the error rate. So it appears the positioning is very important, even with relatively short wires.

After this small step towards better and cleaner power, we hope we can work on something more creative and less frustrating next time!

First Steps (Literally)

2018-11-12T00:00:00-06:00

The story of our new robot (Phantom) starts with a prototype: we are trying to validate our idea first, by using parts from a toy robot spider kit.

On the 13th of October, we went to the Robot Club at Cambridge Makespace to start building our robot. First, we built a very simple (but not that bad looking) walking robot (only legs + motors + battery, no control).

Then came the hard part: the boards which were unfortunately necessary, were (naturally) just the wrong size and shape to go with the rest of the structure.

But that wasn’t the harderst part – no, it was having to take apart the beautiful design and replace it with a jumbled mess of wires:

But now at least it could be a) programmed and b) inspected by a dog:

We tried out several methods of turning and we found that turning on the spot by moving the opposite banks of legs in the opposite direction to each other was possible.

So even though our robot looks like some bizarre walking tower, it can walk and be programmed – what more could you want?

Coming soon…

2018-11-04T00:00:00-05:00

On the 1st of October, an alien visitor landed on planet Earth.

The alien was a Martian meteorite which had been travelling through space for many months before reaching planet Earth. Such landings where fairly common, it was what was inside that was unique.

Two hours after the meteorite had landed, M.E.T. was on the scene. The meteorite was unearthed and taken into a mobile laboratory. Slowly, the shell of the object was removed and it became clear that it would have to be transferred to the main lab. Inside the shell was solid water – already gold to the scientists but inside was something even more extraordinary – a black object, blurred by the ice was glowing a deep, hypnotising purple…

5 hours later, the sample was safely put into the main laboratory of the M.E.T. Complex. The world’s leading scientists examined it and it baffled even them. Once the ice had been safely melted and stored in a sterile container to be studied later, the object inside was revealed. It was clear that this was no terrestrial machine – it was almost like a living creature, only not – it was clearly artificial. It was a robot spider, and it seemed to be powered by a strange orb, now glowing a deep green…