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.
Njay
March 5, 2012
Hey, I know were we’re going to start on the safety features. We’re going to add a relay which will turn off on command from one of the: main controller, bridge 1, bridge 2, user red button.
Vasco Névoa
March 6, 2012
Heheh… you and the Panic Button.
Something like this or this.
Ok, you get us a Big Shiny Red Button, and we’ll set it up.
To keep the system powered, all panic sources must agree everything is ok, so the Normally Closed button (with mechanic latch) must be in series with the Normally Open electronic switches controlled by the bridge microcontrollers and central CPU. Right?
Vasco Névoa
March 6, 2012
The last video is very informative. I love to get stuff like this on tape because there is too much information for us to decode during a live test, but viewing the video afterwards allows us to comb the situation very finely.
There’s a lesson in there somewhere. 
When we accelerate the motors to maximum and release the joystick and the motors fail to decelerate, we can see that the whole main controller is locked up: no more data updates appear on the monitor. When it unlocks, everything comes back to normal. Knowing my code, there is only one place that it can lock-up: the I2C read/write parts.
Now, we’ve already seen that when one of the bridge microcontrollers resets, the bus impedance goes down and the voltage gets cut in half, effectively stopping communications with both bridges. I’m pretty sure this is what blocks the main controller, whose I2C master chip is just waiting for a time-out and hanging the synchronous I/O call. So I really have to get the I2C master chip to be more robust… i.e. decrease the time-out value so that the main code can go ahead with its decisions instead of locking up during several seconds. A time-out of 50 milliseconds should be ample enough.
But the last time I played with I2C timeouts, I fried the smartphone board. The GTA02′s power management chip (battery charger, usb supply, wall time clock, etc) is on this bus too, and so I can’t abuse it too much. I wasn’t seeing any results when changing the time-out, so I tried setting I2C time-out = 0 which made all I2C communications fail. The power chip went nuts, and the board never booted up again.
Furtado dos Santos
March 6, 2012
BRUTAL!!!
Muitas falhas momentâneas… mas que gozo ver aquilo a fazer o que sonhámos durante todo este tempo. Fogo também quero! Aquela pata que está sempre no joy stick é do Rodrigo?
hehehe
Abraços
Vasco Névoa
March 6, 2012
Não, é do Manso.
Gavrila Adrian
March 9, 2012
Some fine tunning to the bord and you are good to go. What is your next project?
Vasco Névoa
March 9, 2012
Heheheh… No, Adrian, we’re not in a hurry to close this project just yet.
There is still much work to do here. We are about to complete the very first phase, yes, but the roadmap is very ambitious and there are several major steps to conclude.
What you see in this page is just a Proof-Of-Concept, a model. It is not the project itself.
You can see in my design posts that we have been dreaming a lot higher; the project involves not just some hardware but also conceptual design and some yet undisclosed advanced fabrication techniques. We’re just getting started here, merely warming up. It’s a pity it takes so long, but that’s how things go when we work with time left-overs.
We’re not a company, we are a hacker collective of friends. So it will be ready when it is.