[GlenTheMachine]

Correct. Basically all the gimbal is doing is minimizing the cosine loss. This is, literally, the simplest loss function possible. Even if you don't know where the sun is, damped gradient descent will solve this problem every time, with no learning required (albeit with some jitter because you're having to estimate the gradient by moving the panel around). If you treat it as an iterative learning control (ILC) problem, though, you can learn the correct trajectory for the panel in just a couple of iterations and take the jitter out.

[snovv_crash]

You can do this without jitter by having the panel with a bend in it and comparing power from the 2 sides. The difference drives a motor controller directly.

[sgtnoodle]

I raced solar cars in college. One car we built had a solar concentrator system made up of 1D parabolic mirrors. This was a several hundred thousand dollar system due to the use of specialized concentrator cells, and required multiple team members to temporarily move to LA for months to delicately manufacture the cells in a Spectrolab clean room.

The concentrator mirrors had to be aimed within about 2 degrees to aim the light onto the active area of the cells. I tried using a pair of photodiodes as the sensor, and it worked well in early prototypes. We flew out to Australia before the system was fully integrated into the car, though. In the real setup it just wasn't precise enough. On top of that, the aerodynamically shaped acrylic window surfaces created weird refractions and reflections that made the accuracy poor as well.

I had a couple weeks to figure something out, with a bunch of PIC18F4680 MCUs on hand, and access to parts from Dick Smith's. I ended up buying a small PAL security camera to experiment with. I went to a nearby photo center and got some overexposed film negative to use as an IR-passing filter. With enough layers of film, the camera image was completely black other than a white dot when pointed at the sun. Looking at the analog video signal on a scope, I was able to rig up a couple fine-tuneable voltage dividers and then use the MCU's dual comparator peripheral to generate interrupts on sync pulses and on white pixels. I could then count scan lines, and detect scan lines with the sun in them, giving me a Y coordinate precise to a fraction of a degree. I also got an X coordinate by timing between syncs and white pixels, but I didn't need it for control. I then mounted the camera on the concentrator mechanism, and wrote a basic PID controller.

It worked pretty well, and we were able to happily concentrate sunlight while driving at highway speeds.

It turned out the linear servo mechanism had a design flaw, where it would lose too much mechanical advantage at the extremes, and in the presence of road vibrations it would jam. We discovered this fairly early on in the race. Luckily I had wireless control of the motor over our telemetry system, allowing me to keep the motor from burning out. We drove a couple hours with the system jammed, taking the power hit over losing race time. Someone realized we would be driving over a "cattle grid" soon, and we had the idea to try running the motor at full torque to see if the shock would be enough to unjam the mirrors. It worked, and we suddenly started getting several hundred watts of additional power! After that day, we tied a string to the mechanism and routed it up to the driver cockpit. Whenever the mirrors got stuck after that, we simply radioed the driver and they gave the string a yank.

[Gravityloss]

Very fascinating story. What's your opinion on the Lightyear partially solar powered up oming commercial car?

[sgtnoodle]

This is the first I've heard of it. The physics of it seems fine. The engineering is going to be very hard for them to get right.

Just skimming their web site, range is qualified as "WLTP drive cycle". I assume that means software enforced torque and speed limits, and no one is going to want to drive with that enabled.

Using 4 independent motors implies they're using in-hub motors. They don't seem to mention a top speed anywhere. Unless their motors have dynamically adjustable air gaps (which I am guessing they don't), the motors will have a fixed KV constant. That means the top speed of the vehicle will be limited by battery voltage at some point. Maybe that limit is high enough not to matter, but it's funny they don't specify it.

Using in-hub motors also means there's a lot of mass on the wheels themselves. I'm not a mechanical engineer, but my understanding is that adding wheel mass makes suspension design a lot more difficult. On top of that, the rest of the car is presumably a couple hundred lb of batteries, and then a bunch of lightweight composites. The batteries will likely be in the floor, which is good for vehicle dynamics. The overall car will be significantly lighter than what people are used to. I think it's possible that the car will have a relatively rough ride, and could possibly have more noise than usual in the passenger compartment.

Crash-safety wise, I wouldn't want to drive that car on a busy highway. In the US, it would likely struggle to pass crash safety testing. I wonder if they are certifying it as a low speed vehicle, which would put it in the same regulatory class as a golf cart. It would have to have a 40kph speed limit on level ground.

It will probably cost more than a Tesla. At the end of the day, slapping a solar roof on a Tesla would probably get a lot of folk to the grocery store and back every few days. Mounting the same panels on the ground and plugging in the Tesla would be even more effective.

[Gravityloss]

Thanks. I would assume you could make the front and rear electric motors optimized for different speeds. That would mean power loss towards top end speeds.

[sgtnoodle]

Maybe, but I would be surprised if they did that. From a manufacturing point of view, having two different motor types is more expensive.

More importantly, the motor drive electronics would have to be designed specifically to support that. A motor's top speed is limited by the supply voltage because a spinning motor generates its own voltage called back-EMF. When back-EMF matches the supply voltage, the motor drive can't push any current through the motor because there's not enough of a voltage difference. When the motor spins even faster than that, its back-EMF exceeds the supply voltage. This does something funny to the motor drive. The voltage across the FETs in its H-Bridge circuit swaps polarity and the FETs become "reverse biased". A reverse biased FET acts like a diode, and allows current to flow through it. As a result, the motor generates a braking torque. The only way for a motor drive to avoid that would be to have an additional semiconductor in series with the H-Bridge circuit. That would make the drive more expensive, and lower efficiency. It could be done, but I doubt it.

It's also hard to optimize a motor to work well at low speeds, but then have it be efficient at high speeds, even if not using it. One of the ways motors lose efficiency are in what are called "eddy current losses". Just the fact that the motor is spinning means that metal is moving through alternating magnetic fields, and that induces eddy currents in the metal. Those Eddy currents generate a braking torque, and heat up the metal.

This all assumes the motors are permanent magnet brushless motors. I think that's a safe assumption since they are in-hub. There are other types of motors, such as induction, that work differently and don't have the same "speed limit" or Eddy current losses when freewheeling. Most electric vehicles use one or two induction motors. They aren't in-hub, though, because they don't scale down in size well.