Eroadarlanda / Elways / Electric charging road in Sweden

What is it?

The world's first electric charging road "opens**" in Sweden. Near Arlanda airport. It can "charge***" "electric" cars while they are driving.

It is a massive press-release that appears to have hit a lot of mainstream media in the last couple of days (12 April 2018)

E.g. The Guardian and a million other press outlets

"Stretch of road outside Stockholm transfers energy from two tracks of rail in the road, recharging the batteries of electric cars and trucks"

They certainly seem to have an excellent PR agency.

Can it do what it says?

 Mostly, no.

They have a truck which apparently can run from this scalextric-type road. It is not clear whether the truck is electric. The truck is electric. Most of the video I can find shows a diesel truck with a dummy electrical load. They also have a test-car (which is, I suspect, petrol-powered, at least it sounds like it in the video) which carries a 17kw dummy load powered from the track. It is not clear whether the car is road-legal with the dummy load (I can only find video of the car being used on a test-track)

Could it possibly work, ever?

Maybe, yes. If it can actually deliver 17kw to a moving vehicle, that is approximately enough to run a car at motorway-type speed and charge at a modest rate simultaneously. 

They made various claims about its safety and robustness etc, which seem at least vaguely plausible. They obviously did some testing in various conditions. There is video of the truck driving in snow.

So what's the problem?

No normal electric car could ever charge from the track while driving. The electrics system would have to undergo major modifications. That's ignoring the major software updates.

That's to say - EVs can recharge while driving - it's called regenerative braking. 

The electric system in an electric car is fairly complex and needs to handle a lot of power in several directions. Most electric cars can charge at up to 50kw, and many will discharge even faster in some conditions. Moreover, they can switch from one to the other in a very short time while driving.

EVs usually have an onboard charger for charging from AC (Level 1 and 2) sources. This is part of the power electrics which can't operate at the same time as the drive.

Rapid charging (Level 3) is done by an external charger, which communicates with the car in a rather complex way, and provides DC at the correct voltage / current for the specific charging requirements of the vehicle. The external charger is a big heavy box which would be prohibitively heavy to put on a light vehicle. They usually take an industrial 3-phase supply.

I don't think it's plausible to use a level 3 charger in the track:

• There aren't enough pins for a level 3 charger, which needs at least an AC supply AND a DC supply.
• There would not be time on a 50m section (or even 200m section) of track, for the charger to get the correct voltage, current etc for the specific vehicle
• The large number of complex level 3 charger boxes would be prohibitively expensive.

There is a lot of difference between delivering some power to the vehicle (which has been demonstrated) and charging an EV traction battery (which has not).

But those things could be solved?

Yes, in principle, but no car maker is going to want to do that. Modern vehicles are not designed for a single market, it's not cost-effective. Cars designed now (without elways support) are going to continue to be made for 20 years without a major redesign of their drive train.

It's not remotely viable to redesign the electrics of an EV for a feature which is available only in one country, as the weight / performance / space penalty would exist in the design everywhere else.

Why else am I sceptical?

 Most of the videos that I've seen seem to be on the test-track (not on the airport highway). I saw one 12-second clip which appears to show a slightly less hacky pickup (maybe on an electric truck) looking like it might be powering the real truck.  But otherwise, all the media seem to be from the test-track, or with dummy loads.

The Guardian's funky video obviously shows a diesel truck with the test-load running some bright lights - this is presumably on the test-track because it won't be road-legal.

The PR is certainly very strong. There is a lot of marketing wank that makes very big promises, but is very light on details.

There is basically no detail whatsoever about any of the vehicles that they have to use on this "open" road.  I understood from the various press releases that there was one truck which would be regularly using the road, which is a 2km section. Again, it's not clear whether the truck actually takes useful traction power from the road (whether charging or just driving), or just drives a dummy load.

* I wish they would spend more money on developing the tech instead of making mockup videos and writing PR stuff

 Anything positive?

Yes a few things

• The tech for getting the track and pickup working seems well developed, they've shown it working back in 2013
• It has been demonstrated working in bad weather.
• If we forget about charging electric cars and just consider an extra power system for (ICE powered) commercial vehicles, it starts looking a lot more sensible.
• Heavier, slower vehicles pay a lower weight and aerodynamics penalty for having the tech installed.
• Delivering 17kw to an electric motor on an otherwise-diesel truck would save it a great deal of fuel, it would also extend the range of an electric one (but not much if you only have 2km)

** opens to the single vehicle it's designed to work with. But other traffic can still use the road, so I suppose that's open?
***  well, not actually charge. But deliver power to. Perhaps?

Why I use Python

There are a lot of holy wars between programming language advocates in the industry.

I use Python.

Why?

Because I have found that programs written in Python are significantly more likely to Work Correctly. They more often run correctly the first time, therefore I spend less time debugging.

There are lots of other reasons, but it's mainly the "It just works".

A few years ago, I had 10+ years of industry experience of Perl, but only 1 year of Python. I already found that my Python programs initially worked correctly FAR MORE OFTEN.

This is comparing a language that I'd been using commercially, most days, for 10 years, with something that I'd only just picked up.

That's why I use Python.

---
Other stuff?

DEBUGGING: Stack traces. In Perl, it's possible to get a stack trace from an exception, but you sometimes have to jump through hoops to do it. Likewise, in PHP, stacktraces are available in principle, but don't always appear when you need them. Java? Stack traces usually appear, but are often huge and difficult to read (even better: in some versions of Java, the compiler "optimises" out line numbers from stack traces) In Python, stack traces Just Work. Like everything else.

HTML 2d Canvas upscaling - really inefficient

I started writing some test programs with the HTML canvas element. This is great, as you can actually write games in Javascript - efficiently - in principle.

My previous attempts have all used the DOM API which is not very convenient, and not very efficient.

I had assumed the canvas 2d drawing context was basically a software-renderer - it's not extremely efficient, but provided the canvas doesn't have too many pixels, you can still do a lot of work per frame on a modern machine.

Which is fine.

Suppose you have a canvas which is 640x320 pixels, you can then get it upscaled into whatever resolution is in the browser window, making the game appear the same size for everyone. Great.

Except, the upscaling in web browsers sucks performance. I tried Firefox 3.6 and Chrome 9. Both of them use loads of CPU scaling the canvas on to the screen.

If we use a canvas element without any scaling (no CSS width etc) then all is fine.

Scale it up to a large window, Boom! now it's slow as a pregnant snail. Bummer.

See Example here

MySQL, what are you smoking?

There are a lot of weird things which MySQL does to handle its mix of transactional and non-transactional behaviour, but this one was new to me :)

create table t1 (ID INT NOT NULL PRIMARY KEY, V INT NOT NULL);

Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 (ID,V) VALUES (2,NULL);
ERROR 1048 (23000): Column 'V' cannot be null

mysql> insert into t1 (ID,V) VALUES (3,1),(4,1);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

insert into t1 (ID,V) VALUES (5,1),(6,NULL);
Query OK, 2 rows affected, 1 warning (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 1

mysql> show warnings;
+---------+------+---------------------------+
| Level   | Code | Message                   |
+---------+------+---------------------------+
| Warning | 1048 | Column 'V' cannot be null |
+---------+------+---------------------------+
1 row in set (0.00 sec)

select * from t1;

+----+---+
| ID | V |
+----+---+
|  3 | 1 |
|  4 | 1 |
|  5 | 1 |
|  6 | 0 |
+----+---+
4 rows in set (0.00 sec)

What's going on?
MySQL does not consider (some) errors to be errors, if they happen on the second or subsequent row of a multi-row insert.

On the other hand, if it happens on the first row, it's an error.

Why?

Because non-transactional engines can't rollback to a savepoint. This means that if it's inserted one or more rows already, to generate an error would leave some stuff in the database.

No, really why?

I don't know. This is not consistent with, for example, a unique index violation, which makes it stop half way through a multi-row insert anyway, and non-transactional engines can't rollback.

So if you insert a duplicate, THAT still generates an error on the second a subsequent row. It's not even consistent!

mysql> insert into t1 (ID,V) VALUES (10,1),(10,2);
ERROR 1062 (23000): Duplicate entry '10' for key 'PRIMARY'
mysql> select * from t1;
+----+---+
| ID | V |
+----+---+
|  3 | 1 |
|  4 | 1 |
|  5 | 1 |
|  6 | 0 |
| 10 | 1 |
+----+---+
5 rows in set (0.00 sec)

Of course if we use a transactional engine, it looks better:

mysql> ALTER TABLE t1 ENGINE=InnoDB;
Query OK, 5 rows affected (0.00 sec)
Records: 5  Duplicates: 0  Warnings: 0

mysql> insert into t1 (ID,V) VALUES (20,1),(20,2);
ERROR 1062 (23000): Duplicate entry '20' for key 'PRIMARY'
mysql> select * from t1 WHERE ID=20;
Empty set (0.00 sec)

But that won't change the behaviour of a multi-row insert with NULLs in invalid places.

This kind of stuff is nonsense and we need it to GO AWAY NOW.

How?

SET SQL_MODE='STRICT_ALL_TABLES'

And now every error is really an error. Yay! Why can't this be the default? (I know the answer; this is a rhetorical question)