Yesterday we had a great hacking session. I had to completely rebuild the main controller, because I somehow bricked the board I was using, but it was worth it. After that was sorted out, the new board performed flawlessly! Yay! The new board has the smartphone display, I haven’t taken it out. Hmmm… what can I do with a touchscreen on the trike?…
NJay patiently made a new “Y” cable to connect the three controllers; we replaced the shielded cable with this twisted cable to reduce inductance of the lines. It worked partially, the signal now has about half the “ringing” that it had before. But there is still space for improvement here, we’ll keep improving the bus signal quality because this is a crucial part of the trike in terms of safety.
Anyway, here is the SoapBox mark II running a simple self-test: rotating both wheels forward and backward. Notice that the right wheel never rotates backward – there was some problem in that power bridge we didn’t know about.
And here you can see NJay’s shiny new power bridge that we built to replace the prototype, kicking the motor back and forth, inverting the polarity at will. The bridge has 5 LED lights: one for the micro-controller, telling us when it resets and when it receives an I²C message, and one for each “arm” of the H-bridge switches. See how the top green and red LEDs alternate when the controller changes direction of rotation.
We noticed the right side was failing to reverse, but we kept rolling with the tests to understand the problem and see how robust the new bus was. Things were looking good enough, so it was time to turn on the joystick and have some fun!
Yesss! it’s starting to feel like something we can actually ride. However, the bad bridge was still causing some bus locking… one of the things we have to do one of these days is design some fail-safe protocols into the bridges. We have to look at each potentially dangerous situation and define what is the best behaviour for each bridge to do in case it looses communication with the main controller. Should it keep doing what it was doing (current behaviour)? For how long? Should it cut the motor loose until new orders come? Should it run a decelerate-to-zero program? And do we need some other channel of communication between the bridges themselves, allowing both of them to activate emergency programs at the same time, even if one of them is OK and the other one has fallen off the bus?… all these questions and more have to be looked at.
But in the mean time, let’s have some fun!
We kept playing with it, and new faulty behaviours emerged. Both bridges started resetting themselves in certain voltage spike situations. You can see the voltage level of the battery (leftmost bar graph on the monitor) going up and down like crazy when we accelerate and invert direction. There’s bound to be some latch-ups and brown-outs in the old bridge controller – we’re investigating this. The instants when the motor goes “thump… thump…thump” is a reset cycle the bridge is doing by itself; it gets a command from the main controller (“accelerate forward at 100%”) which it tries to obey, and something bad happens at the electrical level, making it reset. It then wakes up again, and the cycle repeats. But this only happens with the right side bridge (the first prototype) which was already damaged. Sometimes it worked, sometimes not, that’s how it goes with power electronics systems – there’s just too many physical variables and we have to find them all and correct the most important problems.
We were happy enough with it to put it on the floor and try it out at slow speed, but before we got to do it the bad bridge sparked up and burned. That’s it for that one, it’s dead. Now we really do have to finish assembling the new bridge for the right side if we want to see the soapbox rolling.
Happy hacking! See you next session.