Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.
> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach
For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.
I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.
More blog posts (and open hardware & software) to come, I hope!
> So wheel speed sensors drop out and the car will accelerate uncontrollably?
No, I don't think any of my bench tests suggest that for this car. The torque is minimal throughout, so if the motor was pushing an actual car then it might not move at all. If it did move, even a light touch on the (mechanical) brake pedal would stop it.
My problem is that I had a bench setup with no load on the motor and no mechanical brake. I could have pulled the safety interlock (all EVs have these for emergency first responders) but this stops the motor at all costs - wasn't sure of potential damage to the motor controller circuitry from back EMF.
I appreciate the insight from someone who's worked on this kind of thing formally, thanks.
> Most likely what’s happening is that the creep torque is applying a constant small torque and the wheel sensors are reading 0 continuously, so it continues to apply a constant small torque.
This was also my hypothesis at the time of the post. Turned out it's less constrained than this, a fully operational car with the drive wheels off the ground will also run away to high rpm (even in Neutral): https://www.projectgus.com/2024/04/unremarkable/#on-car-test...
There's still minimal torque, as you say, so a small press on the car's brake pedal is all it takes to stop. However I think if a driveshaft broke on a real car then it'd be spinning fast for a minute or two... It kind of makes sense that the control loop is tuned for a heavy car with a fixed drive ratio, though.
I am still hopeful there will be a way to stop this behaviour via a control signal (rather than pulling the safety interlock and slamming the contactors open). Have left the problem aside until I have a mechanical brake to use for testing! If that doesn't work out then it's still usable I think, provided any EV conversion is single speed fixed gear just like the Kona.
If you have any other insights on this then I'd be very interested to hear them, though.
It won’t happen on a real car because the speed probably comes from the ABS wheel speed sensors, and in that case they would read the correct speed of the wheels (unless the motor shaft is proper broken).
If the ABS is properly plugged in it will detect a fault with the sensors (which probably causes the creep to stop) however it won’t detect a mechanical fault with the encoder wheel (such as sensor not bolted to wheel) — such a fault is indistinguishable from the wheel not spinning, thus zero speed.
I think you were emulating the ABS module right? In that case, the spinning out of control is actually probably your fault. If you had not emulated this, the system would realise there is an ABS fault (from the messages not being present) and not use the ABS reported speed. It might even fall back to motor speed automatically.
Re: shaft scenario, if the motor shaft is broken the safety risk is pretty minimal because the torque wont actually cause the car to move.
Funnily enough I noticed recently that Japanese and Korean engineers usually argue against using checksums and random magic rolling bytes on these messages (“it will never happen”), in contrast Euro engineers use them everywhere. In this case the Euro method although more complex would have let the system know you are spoofing the ABS and no such motion would have happened.
My European car (2013 Volvo) had no checksum or even identifier for the firmware as I found out when my car would just randomly cut all power at speed.
I brought it back to the dealership and they found it had a completely different car’s update (2017 different model) installed!
> I think you were emulating the ABS module right? In that case, the spinning out of control is actually probably your fault. If you had not emulated this, the system would realise there is an ABS fault (from the messages not being present) and not use the ABS reported speed. It might even fall back to motor speed automatically.
That's a reasonable expectation, and this got left out of the follow-up post I linked, but in the "full car with wheels off the ground" tests we actually tried unplugging the brake module of an otherwise working car and it didn't change anything (including the gradual constant rpm increase in Neutral). If anything the behaviour might have gotten a little more aggressive with the brake module missing.
Have now observed similar behaviour for all three of "spoofed brake messages with 0 wheel speeds and emulated checksums", "fully operational car with wheels off the ground", and "car with wheels off the ground and ABS/brake module unplugged". ¯\_(ツ)_/¯
> Re: shaft scenario, if the motor shaft is broken the safety risk is pretty minimal because the torque wont actually cause the car to move.
>
> I guess this is what they arrived to in the FMEA.
Fair enough, that makes sense. I guess if that's the case then the other behaviour is outside of the scope of what they need to care about.
If you're interested then click the link in my first reply (which is to a newer post). The first video shows the working car reaching 8000rpm (about 80km/h) around six seconds after the accelerator was released. The second video shows the speed creeping steadily from 38km/h to 44km/h (~2600rpm) after switching to Neutral (before we got nervous again and touched the brake).
(I don't really understand it, but I also haven't managed to think of a safety issue here for normal car use: the broken driveshaft is just a bit scary as the motor spins unloaded at >10,000rpm for a while. The only other time this seems likely to happen is if a mechanic puts the car in Drive on a hoist, and it'll stop as soon as they tap the brake.)
> I think you were emulating the ABS module right? In that case, the spinning out of control is actually probably your fault. If you had not emulated this, the system would realise there is an ABS fault (from the messages not being present) and not use the ABS reported speed. It might even fall back to motor speed automatically.
If the ABS unit getting stuck causes that kind of acceleration then I'm going to point most of the fault at the control logic.
I have experienced a spurious ABS activation while braking from highway speed on an offramp. It was terrifying, and would have led to a crash had there been any traffic when I rolled through the stop sign at the bottom with the ABS still chattering.
Not really.. it will only be applying 5Nm or so which is such a small amount of torque that you could likely stop the wheel with your hand (equivalent to holding up 500g object with 1m ruler)
He is spoofing an ABS message from a working vehicle that says “no faults present” on a vehicle that is clearly full of faults.
ABS are usually ASIL D rated (ISO 26262) which means they have an on board watchdog, redundant processor with voting system, etc. so this failure mode (locked up and still sending) is considered impossible by design.
sure, but I would think some special case when we expect car to have 0 speed to not request any torque from its motor.
IMO three is no case where car should request any torque when been in neutral
> Not really.. it will only be applying 5Nm or so which is such a small amount of torque that you could likely stop the wheel with your hand (equivalent to holding up 500g object with 1m ruler)
It's good that it's small but I'm still not thrilled about this control loop.
> He is spoofing an ABS message from a working vehicle that says “no faults present” on a vehicle that is clearly full of faults.
My point is that the same messages would happen if you had a fully working vehicle and then the ABS unit locked up in a way that didn't interrupt sending.
Please explain how that is a "no". You just described a situation where it would be doing both when it's not supposed to. In the analogy, the thruster is supposed to turn off once it starts spinning, but it doesn't.
The entire reason this mechanism exists is that resistance can be significantly nonzero and needs to be adjusted for. It's just doing the adjustment in a flawed way.
Sorry if it sounded dismissive, but, I mean, modern motor control formulae[1][2] don't have a term for RPM. Motor controller derives new output state from just torque and instantaneous state of the motor, RPM is somewhat externally controlled unless that version of formula is in use. Hence the capsule analogy: F=ma for constant F means a > 0 and (rotational)velocity monotonically increases.
It doesn't make instinctive sense to me too that motor people haven't been thinking RPM-first for some time, but apparently they're not.
> Motor controller derives new output state from just torque and instantaneous state of the motor
And the way it makes the motor state advance causes acceleration. It doesn't matter what variable goes into the formula, especially since you can convert freely. I'm pointing at the output and what I find scary about it. What comes first doesn't matter, I'd have the same issue even if I'm looking at the control formula from a jerk-first perspective.
And I don't really see the value of the "against nothing" analogy because the reason it's increasing torque is because it thinks there's resistance.
We don’t implement stuff like this because it would go off when you’re going down a slight incline for example, and the more bandaids you slap on it to get it to work, the more complex testing the failure scenario would be.
You're spot on about the PLL stage, a few people on Reddit pointed the same thing out when I first posted it. Makes sense, although I still think it's interesting they added it internally to an otherwise (apparently) cloned design.
You're also right that USB CDC does provide the option for a generic USB Ethernet device, however this silicon is ASIX-specific (not just the USB IDs.) ASIX's Windows drivers include their own system driver binaries, and the ASIX Linux driver has a lot of ASIX-specific stuff in it.
I think it's kind of possible ASIX made this themselves as some kind of no-name branded unadvertised market segmentation effort. I can't understand what their rationale would be exactly but hardware companies do unusual things sometimes...
If you go only on the definition of a clone being "compatible interface", then there are tons of other examples of that in the electronics industry - it's more commonly known for simpler parts like voltage regulators (how many companies make a '7805?), opamps, transistors, etc. but also occurs with more complex ones too.
IC companies make unadvertised products all the time, for anyone who is willing to buy enough... look at Apple's Lightning cable and TI's BQ2025, for instance.
Freescale i.MX6 is a really nice platform. Shame it hasn't gotten broader traction, I think because it is moderately more expensive than its competition.
Since May I've been using an imx6 based gk802 ($70 quad core "Android TV" stick) as a personal server (email, RSS, VPN, etc.) Has worked really nicely considering. (Blog post about installing debian on it: http://projectgus.com/2013/05/debian-installer-for-zealz-gk8... )
I haven't tried any of their other products, but the iMX6 has a very large detailed technical manual (publicly available, not under NDA) and their Linux kernel trees are updated in public via git (presumably not everything is public but it's a lot more transparent than the occasional tarball source drop approach), plus they have people involved in yocto development. Better than many/most of the ARM SoC manufacturers.
The only undocumented/secret squirrel business AFAIK is the Vivante GPU. And that's universal across ARM Soc GPUs, sadly.
I've built the Linux kernel and Android AOSP/ICS directly from their git repos and it all runs just fine. You can ask support questions on http://imxcommunity.org but the response you get will be sporadic. Your best bet at getting answers is to be a real customer and get an FAE to help you out. But otherwise I've never had a problem with a lack of "openness" from Freescale.
Rather than "open sourced" all I see is "a bit open specced". Yes, the "hacker guide" has details of what chips are on the board, and how they are connected:
http://developer.sonymobile.com/services/open-smartwatch-pro...
... and there's a separate page with a guide to putting it in DFU mode to upload a firmware.
Which is cool, but the chip names could have been found by the people who'd already done teardowns and the pinouts could be found by buzzing one out (possibly sacrificially by removing chips.)
The chip datasheets they link were all all already publically available, the Cypress touch sensor one is even a link to alldatasheet.com(!)
Probably the biggest letdown is the Bluetooth/FM chip made by Sony, arguably the most useful and most complex device aside from the MCU. That link is to Sony's marketing specs page with a block diagram and not much technical info that I can see. I can't find any information about the chip made available to the public by Sony.
Ironically enough there is a longer 6 page Sony datasheet leaked on datasheet sites, but even this doesn't have pinouts or begin to explain how the SPI interface to Bluetooth/FM functionality actually works.
I think it's good that a major company like Sony released even this small amount of information, although it's worth noting that reverse engineers have found more information on similar products acting entirely by themselves (take for instance the PS3 Move controller: http://eissq.com/ps3_move/ )
On the other hand I think it's very bad that most people will glance at this and see Sony "open sourcing" something when they appear to be open sourcing nearly nothing. The RTOS they used is probably proprietary property of a third party so they can't open source that, but they could release their application source code for the smartwatch - allowing people to see how they communicate with the Bluetooth/FM chip, for instance. That kind of source could be ported to an open source RTOS.
The optimist in me hopes that detailed technical information will be forthcoming over time, but the pessimist in me thinks this is the feel-good last gasp of an end-of-life product. :/
I agree anyone seriously wanting to host that many photos will not want to split accounts, but FWIW statistics (current Pro feature) don't seem to be offered at all any more.
A number of things - the Z axis seems loose, the other axes skip steps (possibly the stepper drivers overheating), general issues with bed adhesion and warping.
All common 3d printer issues, though some are exacerbated because I bought a cheap kit from an unknown supplier. I got to a point where every time I fixed I problem I'd notice two other ones, and put it down and haven't picked it back up.
Good advice for people getting 3d printers is to decide if you want a printer as a tool for design/prototyping, or 3d printing as a hobby. I told myself I wanted the second as a path to the first, but after many hours of printer building I concluded that I really just wanted the first.
(If there's not one nearby, you could always start one... when I cofounded a hackerspace I met a lot more than 15 new people who wanted to share 3d printers and the like!)
Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.
> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach
For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.
I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.
More blog posts (and open hardware & software) to come, I hope!