Wikispeed collaborative 100mpg+ car

Joe Justice and his friends put together an extremely ambitious engineering project: build a +100mpg commuter car that was really fast, safe, and affordable. Basically, they built it from scratch in 3 months, just in time to participate in the Progressive Automotive X-prize.

They didn’t get 1st place, but they got 10th and got noticed and respected worldwide — and they placed better than Tesla and MIT, which were very well funded! They proved that there is no such thing as “conflicting requirements” or “technical impossibilities” when people are passionate about their work.

And how did they start? quite humbly, by bolting some recycled parts together with a square chassis in Joe’s garage, and using second-hand tools. Oh, and by simulating everything they could inside the virtual world of software. Does this ring a bell?

These videos blow my mind. In fact, they confirm my suspicions: R&D is a lot easier and cheaper to do once you leave the heavy traditional framework (and mindset!) of mass-production companies. And most importantly, a lot more fun!! I’m well aware of how medium and large sized R&D companies operate, but I never knew exactly how completely informal and self-organized groups faired in the field of R&D.

It all has to do with a fundamental change in attitude: embracing change (risk and uncertainty) as a natural part of life and especially innovation, letting go of a priori control measures, and just be light and quick enough to adapt and respond. However, Agile and Lean methodology is definitely not a chaotic mess where people just get together around some tools and do whatever they fancy; it’s almost like that, but everyone has a very precise notion of how they and the others are contributing to the final goal of the team.

The Lean and Agile methodology they follow is a mix of several methods, taking the best parts of each to solve the real life problems as soon as they come up. I already knew about Agile’s power to deliver results soon and adapt fast, but I hadn’t thought it could be used in volunteer or even distributed teams. And I certainly didn’t expect newbies to become productive so fast and everyone to have so much fun while doing world-class competition and development. This is a case-study to inspect and remember with great care.

So what do we take away for our project?

Since we are not in the position of wikispeed (having an external and very demanding client wanting results yesterday), we don’t yet need to accelerate the development so radically. And since the team is quite small and steady, we also don’t have a clear need for extreme modularization (although we have been using it). But we do have to cope with changing requirements, since our clients (ourselves) keep changing their minds about what they want. Basically, we grow more ambitious the more we learn. And we do have to produce results with a shoestring budget, so the Lean aspect also comes into play.

It really does look like a good idea to implement Agile and Lean at MyOwnHybrid.

In some ways, we are already doing it; we always try to get together face-to-face to work on the project; we try to work in pairs or in threesomes in order to have implicit on-the-job learning and fast cross-correction and problem unblocking; and I’ve tried to at least maintain an electronic version of lightweight project management in a private server that all team members can access (but usually don’t ). Also, the publication of results in this blog is a kind of “Sprint Review” (the Show-And-Tell session that the Scrum method does of results to the customers).

So, using Scrum terminology, we’ve been operating as a “Feature Development Team” that tries to implement the “Product Backlog” created by the “Product Owner” (me), only without the benefit of a “Scrum Master” to help people cooperate and grow their skills.

This is clearly not enough — motivation and commitment could be a lot higher. I think it’s time to put up an old-style “Sprint Task Board” in our workshop, complete with sticky notes and all, and run a weekly Scrum meeting at the beginning of every encounter. This alone should be able to pick up the pace of development and give a sense of cohesion to the team that is now a bit lacking.

It is very important, from a psychological and emotional point of view, to be aware of what it is the whole team is building, how much it has already achieved, and how much work remains to be done. Another fundamental point is to avoid over-specialization and promote task swapping and collaboration: we are here to learn and have fun. So a weekly Scrum should give us more opportunities to do just that.

And when this present sprint/iteration ends, it is also a very good idea to hold the “Sprint Retrospective” (a “Lessons learned” gathering) and do a full-blown “Sprint Planning” meeting to determine exactly What we want to build next and How we want to build it.

None of this had been an issue until now due to the simple fact that I had been working alone; but from the moment other people started contributing to the project at many levels, the simple process that went on in my head is no longer valid. I had been struggling with this reality without knowing exactly how to transition from one-man-band into team mode; but the Agile methodology came to our rescue.

All this does not come by chance; I’ve just completed a Scrum Master course in the context of Software Project Management, and after seeing how Wikispeed has done it for a manufacturing process I believe that all innovation projects are a natural fit for Agile/Lean methodology.

I do have a problem though; I shouldn’t be Scrum Master (the guy that coaches others into the Agile process) and Product Owner (the guy that decides what effectively should be built for the product) at the same time. I need to offload one of the roles onto someone else. But I clearly have stakes in both of them. Hmmm… any volunteers?

Another lesson I learned from the Wikispeed example is that I should be more transparent about the problems we have. This blog doesn’t have a whole lot of followers, but the few that hang around will probably feel more engaged and interested if they can help us solve our problems. So I’ll start doing that more.

NJay brought the prototype of the power electronics H-bridge he so lovingly hand-crafted for us, and he tested it on site with a small DC motor from a Meccano set. We didn’t want to push too much current so we avoided the 250W trike motor in the beginning. He used his own homebrewed I²C Master console to verify that the bridge was working properly, which Manuel was more than happy to explore.

Then it was time to connect the Freerunner board as the I²C Master and we did a simple up-and-down power cycle with that small motor. Now, the motor is rated for 6V and the battery is supplying over 24V, so we kept this test to around 20% of PWM duty cycle to avoid burning the motor.

Ok, everything seems to be working. It was time to launch the full control program and play with the trike’s joystick. Here the PWM duty cycle limitation was not present, but I figured it was safe to risk it because the motor was not loaded and the joystick would allow us to reduce power if we wanted to. In principle…

By this time is was very apparent that something was wrong; the motor was responding in a very jittery way, and the software got completely locked up. I found some accidental floating point truncation errors in the code, and we repeated the test.

Nope, that won’t fly either. Although the software was behaving a lot more linearly, it still got stuck in a bad place when we pushed the motor to the maximum speed. After some mental review of the situation I decided that the problems where due to electric spiking or induced noise on the I²C bus introduced by the motor. After all, this was a DC brushed motor and it was being driven far beyond it’s specifications; it is only natural to assume it was sparking like crazy on the inside.

We tried the test again after attaching a 100nF capacitor to the motor’s terminals, and yes, it improved a lot, but it was still a bit glitchy. As this point I ignored the looks on their silent faces which screamed “your software is still buggy!” and decided to test with the Trike’s 250W motor. And I’m glad that I did.

See? No more interference, no more I²C bus lost packets and retries, no more software lock-ups or exceptions. It’s this kind of multi-disciplinary problem that makes embedded systems development such a great domain to work in.

Obviously, the software must be made more robust in order to resist I²C losses and errors. But we were quite happy to see the wheel spin at the command of the joystick.

Not bad for a single day’s work (plus ten months of R&D)! Now we have to build the 2 new power bridges that NJay has redesigned from this initial one, and we’ll be ready to test the full 2-wheel system. Can’t wait for that one!

Oh, and there’s also that minor detail of the motor running backwards, but that’ll be all sorted out when we have the 2 bridges.

Happy hacking, and see you on the next development sprint!

Manuel Furtado dos Santos is a Fine artist with quite an experience in handling materials and expressing complex ideas and concepts with them. Like me, he has a tendency towards technology, but he far exceeds my culture in such areas as biology, history, and philosophy. I do like generalists. And we are both interested in practical sustainability and in contributing with something useful to the future.

So he jumped at the chance to take my ideas and turn them into a real integrated design. The first hurdle was to get him to absorb whatever was swimming around in my head to serve as a starting point; this was no easy task, mainly because we hardly knew each other, and our vocabularies where literally worlds apart. It took a few months to get aligned, but today we pretty much understand each other well. And when we don’t, that’s usually where new value is being created – our discussions are frequently intellectually exhausting (for me at least, because he never stops!) and whenever we drift apart that usually means he’s on to something new and possibly exciting.

He immediately conducted an exhaustive study of recumbent trikes and velomobiles on the Web and proceeded to model with his own hands what he had understood the project was about. Here is Manuel’s handy wire work:

Wireframe model of a foldable trike chassis.

Wireframe model of the whole "velomobile-like" trike.

...and the door swings open!

Now, if I was looking to make a conventional trike or velomobile, he would be quite close to the finish line. It was merely a question of styling and detailing it down to specifics, and it would be almost ready for production. Unfortunately these models follow the conventional form which, as I explained in the previous post’s video about “dynamics”, simply cannot survive my differential-traction-with-a-freewheel platform.

So, a couple of physics lessons and dinners out later, he totally understood my madness. The issue that I created with the centre of gravity is so central to the stability of the vehicle, that it has to be incorporated in the design from the very beginning. The usual proportions of traditional Trikes are useless for us.

Another aspect we started working on was the specifics of the folding frame. He played with a few materials in order to get a feeling of what it is that we really want to build…

Meccano model of the folding chassis (reproduction of my naive Lego version).

We also spent a little time playing with more Lego...

But ultimately what he enjoys working with the most is wood.

When the full weight of the problem was transferred into his head, things really started to pick up the pace and get interesting…

Then he finally kicked it into high gear and brainstormed with transparent paper. These are "some horrible sketches" that I find absolutely fantastic.

At this point I thought that the design process was going too slow because he was limited by his tools. He had doubts about whether the parts would all fit and slide together, and I wanted to see what he could create inside a virtual world without the limitations of the physical world. We could have gone full-power and put him on Solidworks, but I wanted to keep within Freeware and, if possible, Open Source software. Besides, the last thing I’d want is to kill the creative spark of a designer with the heaviness of a full-blown finite element engineering tool.

We set up with Google Sketchup because it was easy enough to use and it looked like it could do some pretty amazing stuff. And it promised a little bit of Physics simulation with plugins like SketchyPhysics too.

And Manuel started to really create…

Well, enough procrastination, let’s publish it.

As some of you may remember, it all began with a simple enough drawing on a piece of paper back in August 2009:

Initial "paper napkin" concept for the Difftrike Project.

There are many things wrong with this drawing, but at least it was a concrete starting point. You can see how I was influenced by Jake Loniak’s excellent Silhouette, but I put in my own set of demanding requirements. It had to be foldable and fit in a small elevator along with the passenger, and also under an office desk or dining table without too much clutter. It had to fit well inside a normal bicycle lane and occupy as little space on the road as a common bicycle or motorcycle.

It had to have such a simple mechanical design that it would be at the same time cheap to manufacture and elegant (I know, the drawing is not exactly gorgeous, but then again I’m not a designer, it’s just an idea). And, of course, it had to have some other distinctive trait like the third wheel being an omni-directional sphere…

6 days after this I built a Lego concept because it was getting difficult to explain all the features in just words or pictures. So here is the result of about 9 hours of fighting against the random intricacies of Lego parts:

This looked more or less cool, but it was still just a “tadpole” trike with a crazy wheel at the back. I had to show the folding system as well…

And for some extra dose of awesomeness, it had to be super-easy to fold/unfold, in fact it had to be completely automatic…

But every idea has its problems, and the initial concept sure had a few. Right out of the bat I knew that the mechanical choices I had made were very troublesome and that this design would have to be morphed into something different in order to be safe to ride…

And this was the starting point. From here on, the cute little lego thingy got people excited about the idea. But mostly they said “it can’t be done, you’re cramming too many features into it”. Or worse, they would start making the design so complex, with robotics actuators and whatnot, that I would just give up on the whole thing.

And to make matters worse, I’ve always insisted that I’d like the whole thing to be as “cradle-to-cradle” as possible, with a preference towards the “natural nutrient” side instead of the “technical nutrient” side. Which means to me: 80% bio-degradable materials, 20% recycled (and recyclable) materials.

My mantra was, and still is to a point: “it has to be as elegantly neat as the iPhone”. Go on, roll your eyes at Yet Another Apple Plug. But that’s the truth; I’m not going to compromise on this point. It has to have a really simple and elegant frame and design, regardless of how many features it actually has. It’s like Amory Lovins says: If every component doesn’t have at least 3 different functions, your design is wrong.

We just have to keep working on it until it does what we want it to do.

• The “Add-on-HEV” project (2007 ~ 2009), where I wanted to convert my car to a Hybrid Electric Vehicle by adding on some electric gear;
• The “MotorFemmulator” project (2007 ~ 2009), where I built a software framework to automate the design, simulation, and optimization of electric motors;
• The “DiffTrike” project (2009 ~ ongoing), where I and a few friends are developing a new incarnation of Hybrid vehicle.

I also added a “Dimensioning” category. I could have just gone ahead and ignored all this, but I like to keep things tidy so I created new categories for the posts and re-tagged them as appropriate. So now, for historical interest, we can click on the category cloud and get just the posts for each project. I also added a “monthly archive” drop-down to allow access to older posts.

So, how do you turn this:

Photo copyright: Tom Yates, teaparty.net

Into this?

DiffTrike Proof of Concept "SoapBox Mk II"

First I removed all the plastic covers and internal accessories that I didn’t need. It’s going to have its own box and a few new wires anyway. The phone battery is unnecessary because it will be fed via USB from the main vehicle battery through a DC-DC 5 Volt “buck” converter. Then I added an RS-232 to USB converter from Sparkfun; it’s cheap and converts the 3.3V RS-232 debug serial port of the GTA02 into a USB virtual serial port that any decent computer can talk to. Both boot loaders of the GTA02 (“Qi” and “U-boot“) have serial console support, and U-Boot even lets you test the hardware. This is probably the most important accessory you can have attached to a processor board: without it you won’t be able to find out why the heck it doesn’t boot when it doesn’t boot. It’s also a good ally when you realise you’ve just knocked out all the network interfaces and you can no longer SSH into the device. Glue it onto the GTA02 board and solder the Ground, Rx, and Tx lines. Power comes from the USB plug. No, it can’t power the GTA02 too.

FT232R breakout board from Sparkfun

My main preoccupation was to set up a development platform that was very fast and easy to develop upon, and yet still allowed for near real-time performance – I’d like to be able to do at least 10 input/computing/output cycles per second. Nowadays the interpreted languages (Perl, Python, Java, etc.) run quite easily on a 400MHz processor like the GTA02 has, so that was my general intention. Interpreted languages do not require compile time or installation, and so I can develop the code directly on the target system without the need for a cross-compilation environment on a workstation.

At the time I started the project, the most complete and flexible Linux distribution for the GTA02 was SHR-Unstable (in my opinion). It’s actively being developed and it’s got a bunch of pre-compiled software packages that we can download and install directly into the target device with a simple “opkg install …” command, as long as it’s connected to the internet. Connecting to the internet is also easy to do, whether by USB or Wifi.

Of course, the SHR-U distro has all kinds of bells and whistles that make it appropriate for everyday usage as a telephone. I picked a few significant targets and “opkg remove …” all the graphical, PIM, and telephone applications. No worries there, Linux package managers are far superior to that other popular operating system on which the uninstallers always leave a trail of bread crumbs the size of elephants.

The SHR and FSO daemons, as much as I admire them, had to go too; I need all the CPU to myself. And I also don’t need power management software creating “funny” behaviours in my target system. So, after all this, I got a clean system just waiting for my commands. In idle state, “htop” consumes around 10% of the CPU time.

HTOP view of the bare-bones system.

It’s time to install the software packages I need. I settled on developing with the Python language because it is easy, fast, powerful, and the native interpreter is already part of the distro. It’s got a large bundle of extra modules that can be installed, namely the all-important “PyGame” module that greatly simplifies the building of near-real-time applications (like games). It saved me the work of writing a USB Joystick device library in Python.

You can get the full customization script for the SHR-U image from my project’s repository.

After setting up the GTA02, I developed my project’s applications right there on the target. It’s quite practical; I connect to the GTA02 via Wifi ad-hoc and just use SSH to send console commands or edit files remotely (Debian systems using the Gnome graphical system have direct integration of SFTP in the Nautilus file explorer). Couldn’t be simpler. No compilations, flashings, downloads, or installations. Just open the file remotely on your laptop, change it, save it, and restart the application on the target: voilà, you can see the new version running.

Here you can see the process list in “htop” with the current version of my software running.

HTOP view with the SoapBox2 application running.

You can see there are 6 processing threads in this Python application called “sb2.py”. They are: the main thread (which runs the endless computing cycle), the LED blinking thread, the GPS input thread, the Accelerometer input thread, the Telemetry server thread, and the PyGame event pump thread. The motor power controller communications don’t need a thread because they are polled from the main thread. You can also see that the entire application currently only uses about 6% of the CPU time, although that doesn’t account for the kernel time that is used because of it. And that the “niceness” number (the relative processing priority) has been set to -10 to confer a higher priority of this application over everything else running in the system.

The whole software chain is composed of:

• An “/etc/init.d/” service daemon (written in Bash) that tweaks the system and then launches the main application on boot-up;
• The main Python application;
• Several Python modules that help deal with devices and such.

The first tests I did with NJay’s micro-controllers connected to the GTA02 revealed that each I²C read/write system call was taking more than 20ms. Since I needed to make at least a dozen of them per cycle, it would be impossible to have 10 cycles per second. After much measuring and researching, I found that the linux kernel was to blame, and that the patch for this problem had already been submitted over a year ago. So I upgraded to the latest experimental kernel in SHR-U and problem solved: each I²C access is actually faster than 1ms.

Or not. Sometimes an access gets delayed by about 20ms again. The I²C bus is shared between 2 other things on the GTA02: the “Wolfson Codec” (a.k.a. the sound card) and the PCF50633 (a.k.a. PMU – Power Management Unit). And the PMU issues one interrupt per second which is serviced by the Linux kernel because that chip is where the RTC (Real Time Clock) of the system is. So once a second, there is a train of large data bursts between the kernel and the PMU, and it was spoiling my average and made my application’s math more difficult.

So to shut up the unnecessary chatter on the bus, I removed all the kernel modules that had anything to do with sound, and reprogrammed the PMU’s interrupt controller to stop issuing the “every second interrupt”. At last, I²C silence! This configuration has to be done after every boot up. It soon became obvious that a custom made boot-up script was necessary to configure the GTA02 just right: from network interfaces to accelerometers and USB, passing through PMU and GPS, all the start-up configurations are done there. One of the things I do is to send a bunch of configuration files written in binary format to the GPS device; this makes it less NMEA-verbose and cranks up the speed to 4 samples per second. I may even use file storage for “Assisted-GPS” fast start one of these days.

Well, that’s it, folks. Use and abuse at your own discretion and responsibility, all the code (including set-up scripts) is in the repository.

Enjoy!

The seat back is a freecycled automotive child seat. The back is attached to the structure of the Trike by a couple of hinges, so that the angle of leaning can be adjusted by adjusting the length of rope. This helps us manage not just the comfort of the rider but also the mass centre placement in relationship to the main axle. We’ve also integrated the joystick into the right hand side of the Trike after a few ergonomic tests. It’s actually quite comfortable! You can also see the battery pack box (long black thing in the middle), the main controller box (dark gray thing with an antenna sticking out, right in front of the seat), and the GPS antenna  at the front end of the Trike.

Now a close-up of the battery pack insides. We’re using the lithium-ion battery pack from an electric bicycle. The pack died a somewhat sudden death after about 8 months of normal usage, it just refused to let me use its charge. It turns out that  the charger that was supplied with the bicycle has a charging voltage of 42V, but the cell chemistry (NCM) only allows a maximum of 4.1V per cell. And since there are 10 cells in this pack, each got 4.2V at the end of each charging. Talk about planned obsolescence!! I don’t know who screwed up, the Chinese supplier or the Portuguese integrator. Of course, the guarantee for lithium packs nowadays ends at 6 months (and now you know why).

Anyway, you can see the 3 first cells on the left side are slightly bloated; these no longer hold any useful charge (I tested them). So, I’ve wired the pack to be charged through 10 cells just the way it was, but to be discharged from only 7 cells, yielding full power at 25.2V (3.6×7) instead of no power at 36V (3.6×10). Which is close enough to the rated 24V of the motors (lucky bastard). I removed the part of the BMS circuit that cuts the power supply when some trouble criteria is met, and I left in the voltage-balancing part to help during charging. One of these days we’ll have to hack the charger down to 28.7V (4.1×7) too. The over-current protection will be implemented in software – which is just fine in this early stage proof of concept.

So now, on to the main dish: the controller. We freecycled a cable modem case and glued and screwed-in the following items:  one Neo Freerunner GTA02 motherboard, one 5V DC-DC switched converter made by NJay, one Wifi antenna freecycled from a wifi router, one USB female plug, one big-ass retro-style power switch, and a handful of spaghetti wiring. Oh, and an external GPS antenna.

Here’s a close-up for you. It looks messy, but that’s just looks. It’s actually very well organised. The external wifi antenna improves wifi remote monitoring from the laptop by several orders of magnitude, so it is a very cool addition.

On the top left corner is the DC-DC 5V converter; on the lower right corner is the GTA02 board with 2 cables coming in at the top edge: a USB power supply / connection to the joystick, and a coaxial from the GPS antenna; On the top right you can barely see the butt of the wifi antenna and its thin cable; and at the top centre, hidden behind the GPS cable, you can see a few solderings that hold a couple of pull-down resistors on the USB data lines, as well as the 5V power distribution from the DC-DC board to the GTA02 and to the Joystick. The GTA02 has also a few wires sticking out (brown, brown/white, red), which are the current implementation of the I²C bus connection to NJay’s power controllers (not in picture).

And now, a sneak peak into the much anticipated power controllers NJay is building for the motors:

This baby has been in labour for almost 5 months and over 38 hours of development and testing have been logged to this task. Why buy something simple when you can build something complicated?! Anyway, we’re all sitting at the edge of our seats while waiting for NJay to finish preliminary fire-up tests so that we can get to real-life testing with all the gear on the Trike.

And then, it’ll be like the other guy said: “I feel the need… the need for speed!!!”

I haven’t had much to say publicly, because development has been going on behind closed doors with a team of volunteer enthusiasts and I’m still seeing where this is going.

Current status is:

- the SoapBox MkII is nearly finished and most of the materials are there, it just needs a few hammer and screw touches to assemble;

- the power controllers for the motors are rapidly taking shape on NJay’s workbench, they will be smoking pretty soon;

- the basic control software and firmware is mainly done, we just need to iron out the bugs with a bit of integration testing.

- the remote monitoring software is taking shape and getting fancy, it may need some rearranging one of these days so that people other than me can understand it…

That’s all folks! Keep tuned in.

First, due to some brainstorming done with my growing team of highly motivated consultants (you know who you are!) I’ve switched the third wheel from the back to the front, effectively transforming the SoapBox from a “tadpole” into a “delta” type of trike. This helps making it more stable during hard braking, and it won’t hurt much in the remaining situations. A typical tricycle is more stable in curve if it is a “tadpole” type, but this is not a typical tricycle… I’ve also made another back for the seat which is now lighter, stronger, and more comfortable, and I’ve put the mass centre much closer to the main axle. Of course, the mass centre can only be determined definitively with all the components installed, including the batteries – but the driver’s butt should be close to the main axle, that’s for sure.

You will notice that all the electronics have been stripped off the SoapBox, and even one motor is missing. This is done while waiting for the new electronics, and the missing motor is being used to test that in the lab bench.

Now for the lengthy and boringly uninteresting video descriptions.

Here’s the DiffTrike control system I’ve been building in the last few weeks. There’s the video description of the system components…

The DC-DC converter was custom built by my electronics wizard friend NJay (of embeddeddreams.com fame), who is also developing the H-Bridge power boards with which I will control the electric motors. But while he doesn’t get me something to play with, I have to stick with blinking LEDs.

And now a demonstration of the small but significant results…

The source code of my software (currently implemented in Python) is, as usual, available in a public repository with an Open Source license (GPLv3). You can download the latest zip or tarball or clone the project and contribute some changes through Git.

Well, that’s all, folks! Keep hacking!!

I can’t get over the fact that GM has killed the electric car once more. The first time they built it just right and then removed the car forcibly from the hands of their happy everyday drivers, and this time they engineered it all wrong to please the massively ignorant public. The whole story is a mishmash of terrible details. How can the right idea go so wrong in just a handful of project years? It started out beautifully as a series-hybrid concept, and now it comes out to the dealers as a Prius “me too”, with just a plug and a larger battery to speak of.

In my view, GM’s “Voltec” drive train is fundamentally equal to Toyota’s “HSD” drive train. I bet they made quite an investment in patent lawyers to avoid being sued by Toyota for such a similar system. I can’t find any fundamental mechanical difference between the two. Well, maybe it is a little more flexible in its available modes because it’s got more clutches. But in the end, it all comes down to software; as long as the promise of a “pure” EV with range-extending ICE is kept by the system controller, the gamble will stick.

In truth, a series-hybrid DOES NOT NEED a planetary gear at all. It is only there in these two hybrid power trains because it is a clever way to maximize energy efficiency when you have 3 motors with different efficiency curves in the same place. Yes, I admire the depth of engineering that both Toyota and GM have gone through to brings us energy-efficient cars, but they are still missing the point altogether!!! More complexity and more engineering does not make the results better, just different! GM fell exactly into the same trap that Toyota did; they gave in to the temptation of reusing parts and systems already present in their production chain, instead of being bold and engineering the correct solution from scratch. They did the right thing in the battery project, but then threw it all away by designing the drive train around the combustion engine!! Damn!… I feel betrayed! I’m taking the “Chevy Volt” link off my blog!

I think I’m going to cry now… there are no series drive train electric vehicles on the market after all. The promise of a highly tuned and optimized serial system remains to be fulfilled. booh hooh hoo….

Which brings me to the Nissan Leaf. Given my disappointment with the current market of electric hybrids, you’d think I’d be happy to see the real pure electrics arriving, right? Wrong!! Even at the risk of sounding like someone who is always against the tide, I just can’t swallow an EV that weighs 3 times and costs 2 times what it should!! Never mind the fact that it is a four-seater that just prolongs the problems of lack of parking space and traffic congestion in our cities; let’s just focus on the product engineering problem.

Just like all the other big brands, Nissan have missed the target completely by taking a standard car platform and (I can’t believe this) reinforcing it!!! “Why of course, the battery adds a lot of weight to the car, so we had to make it sturdier to withstand the same crash-proof tests”, I hear the Nissan engineers say. Well, how about re-engineering the whole car to be lighter in the first place, so the battery weight wouldn’t be an issue?!! Picking stronger materials, reducing and redesigning the structure altogether, picking new lighter materials for the interior (make them biodegradable in the meantime), none of that passed through their minds?? It didn’t even dawn on them that a lighter car would need a lighter and cheaper motor/electronics/battery, which would significantly reduce the final price of the whole vehicle!!??

Of course not; maintaining the current production chain at work is, after all, the main objective. Ahh, crap, I’m getting more and more demanding in my old days.