Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Bit more done. The serial port to the ESP32 now runs at a fixed 5.25Mbps which is the fastest speed that both the F405 and ESP32 are happy with. Looks OK on the bench with no dropped characters but will have to see how well it copes when more motor amps are flowing. This means that the binary logging, which is now ported across, can still capture all the data at the new control loop rate of 16kHz.
The binary logging is mostly working but there are still a few bugs with the data formatting on a couple of parameters. The logging also now has en extra set of buffers which allows most of the code to run in the terminal thread without the danger of missing packets when the 10ms and 100ms interrupts run.
The binary logging is mostly working but there are still a few bugs with the data formatting on a couple of parameters. The logging also now has en extra set of buffers which allows most of the code to run in the terminal thread without the danger of missing packets when the 10ms and 100ms interrupts run.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Good news - the binary logging is now working ![Smile :-)](./images/smilies/icon_e_smile.png)
Bad news - it has shown that the hiccup when running is not a poor connection but something more serious - no idea what![Sad :-(](./images/smilies/icon_e_sad.png)
This is a typical plot from the binary logging opened in PulseView. It shows the key input and control values during every pass through the control loop: You can just about see one of the hiccups at 1.31. This is what it looks like zoomed in: What seems to happen is the PWM values go a bit strange for around a quarter of a cyle for no obvious reason and then just go back to normal. The motor currents, setpoints and angle all look fine at the point it happens. The odd PWM values then cause a fairly big current spike which causes the audible knock from the motor. The only thing I'm slightly suspicious of is the resolver, I would expect to see a variation in the angle plot during the disturbance but it looks clean - wondering if the resolver IC is loosing lock for some reason? Need to do a bit more digging, and add checks on the resolver error flag, but not today!
There also seems to be a bit of noise on the motor current waveforms around the zero crossing. Not sure whether this is real or an artefact of the way the logging data is sent, again bit more work needed.
![Smile :-)](./images/smilies/icon_e_smile.png)
Bad news - it has shown that the hiccup when running is not a poor connection but something more serious - no idea what
![Sad :-(](./images/smilies/icon_e_sad.png)
This is a typical plot from the binary logging opened in PulseView. It shows the key input and control values during every pass through the control loop: You can just about see one of the hiccups at 1.31. This is what it looks like zoomed in: What seems to happen is the PWM values go a bit strange for around a quarter of a cyle for no obvious reason and then just go back to normal. The motor currents, setpoints and angle all look fine at the point it happens. The odd PWM values then cause a fairly big current spike which causes the audible knock from the motor. The only thing I'm slightly suspicious of is the resolver, I would expect to see a variation in the angle plot during the disturbance but it looks clean - wondering if the resolver IC is loosing lock for some reason? Need to do a bit more digging, and add checks on the resolver error flag, but not today!
There also seems to be a bit of noise on the motor current waveforms around the zero crossing. Not sure whether this is real or an artefact of the way the logging data is sent, again bit more work needed.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Couldn't leave it so ended up having another look.
First the resolver was throwing an error but it wasn't actually affecting the measurement. It was complaining about being overdriven so I added a 33R resistor in series with the feed to the resolver (temporary bodge - don't want to tune the drive levels properly as this is just the HSG test motor) which brought it back within limits. Reran the test and no change, no resolver errors anymore but the hiccup was still there.
Next had a good look through the code and noticed that I still had syncadv in (which I thought I had commented out for initial tests). Now this could explain the results. On the plots is looks like the angle rapidly advances and then drops back, exactly the kind of thing a misbehaving syncadv could do so I commented out the line and tested - no hiccup. Syncadv is dependant on the filtered motor frequency so next I replaced idc with frqFiltered in the logging and re-ran to see what was going on.
First a plot just to check the new frequency logging code is working: Looks reasonable, the motor can be seen speeding up and slowing down and the hiccup can be seen around 2/3 of the way though. Zooming in gives: I've had to change the scale to get it to plot correctly but the frequency, which is normally around 20, shoots up to around 1500 before coming back down (note it's overflowing on the plot as I only scaled it to handle 1000Hz) exactly at the point the hiccup happens (and slightly before anything else changes). This clearly explains why the PWM goes a bit nuts.
Next to try and figure out the root cause! Glad I ported the logging code across, not sure I'd have ever found this without!
Edit - Just done another capture of frq rather than frFiltered and this is the result: So it's still there, frq goes up to about 1500Hz too. Now this is largely back to the standard integer arithmetic F103 code (just with a cast on the result to get to a float and a different resolver interface but neither of these should make a difference) which suggests that this might also be in the standard F103 code??
Edit - no idea what the root cause is, it all looks fine - going to have to look at it fresh another day.
First the resolver was throwing an error but it wasn't actually affecting the measurement. It was complaining about being overdriven so I added a 33R resistor in series with the feed to the resolver (temporary bodge - don't want to tune the drive levels properly as this is just the HSG test motor) which brought it back within limits. Reran the test and no change, no resolver errors anymore but the hiccup was still there.
Next had a good look through the code and noticed that I still had syncadv in (which I thought I had commented out for initial tests). Now this could explain the results. On the plots is looks like the angle rapidly advances and then drops back, exactly the kind of thing a misbehaving syncadv could do so I commented out the line and tested - no hiccup. Syncadv is dependant on the filtered motor frequency so next I replaced idc with frqFiltered in the logging and re-ran to see what was going on.
First a plot just to check the new frequency logging code is working: Looks reasonable, the motor can be seen speeding up and slowing down and the hiccup can be seen around 2/3 of the way though. Zooming in gives: I've had to change the scale to get it to plot correctly but the frequency, which is normally around 20, shoots up to around 1500 before coming back down (note it's overflowing on the plot as I only scaled it to handle 1000Hz) exactly at the point the hiccup happens (and slightly before anything else changes). This clearly explains why the PWM goes a bit nuts.
Next to try and figure out the root cause! Glad I ported the logging code across, not sure I'd have ever found this without!
Edit - Just done another capture of frq rather than frFiltered and this is the result: So it's still there, frq goes up to about 1500Hz too. Now this is largely back to the standard integer arithmetic F103 code (just with a cast on the result to get to a float and a different resolver interface but neither of these should make a difference) which suggests that this might also be in the standard F103 code??
Edit - no idea what the root cause is, it all looks fine - going to have to look at it fresh another day.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Hopefully fixed ![Smile :-)](./images/smilies/icon_e_smile.png)
It's been running for a while and no hiccups yet.
Haven't got a definitive cause. I'm 90% sure that it was due to the UpdateRotorAngle() function (which updates the rotor position from the resolver) being called from the PwmGeneration thread while the UpdateRotorFrequency() function (which uses the updated rotor position to calculate the speed) was called from the scheduler thread. I think what was happening was that the UpdateRotorFrequency() function was being interrupted mid calculation by the UpdateRotorAngle() called from the PWM ISR (which has higher priority). If the timing was just wrong this would upset the calculation and produce the error.
I tried all the usual tricks to fix the problem while maintaining the original code structure but nothing seemed to work - wondering whether the compiler optimisation was doing some clever code reordering that I don't fully understand. In the end I moved the UpdateRotorFrequency() function into the PwmGeneration thread (essentially it runs once every 160 runs of the control loop so maintaining the original 100Hz update rate). This seems to have fixed it.
So a question - is there a good reason why the UpdateRotorFrequency() should be called from the scheduler thread?
I've no idea whether this issue is present in the F103 and have no real means of checking; it could be. On my setup the hiccup lasts for 10ms and is fairly slight, noticeable but only because the motor is running so smoothly. If it was hooked up to a gearbox I'm not sure whether it would be obvious. It's also fairly low rate, on my setup with a 16kHz interrupt rate it happens around once a minute, with the standard 8.8kHz rate I'd guess it would only be once every 2min. If anyone is running a bare motor with the standard F103 code I'd be very curious whether you do see/hear the occasional hiccup when running it (just a slight knock and a slight brief dip in speed).
Still running on the bench and still no hiccups![Smile :-)](./images/smilies/icon_e_smile.png)
![Smile :-)](./images/smilies/icon_e_smile.png)
It's been running for a while and no hiccups yet.
Haven't got a definitive cause. I'm 90% sure that it was due to the UpdateRotorAngle() function (which updates the rotor position from the resolver) being called from the PwmGeneration thread while the UpdateRotorFrequency() function (which uses the updated rotor position to calculate the speed) was called from the scheduler thread. I think what was happening was that the UpdateRotorFrequency() function was being interrupted mid calculation by the UpdateRotorAngle() called from the PWM ISR (which has higher priority). If the timing was just wrong this would upset the calculation and produce the error.
I tried all the usual tricks to fix the problem while maintaining the original code structure but nothing seemed to work - wondering whether the compiler optimisation was doing some clever code reordering that I don't fully understand. In the end I moved the UpdateRotorFrequency() function into the PwmGeneration thread (essentially it runs once every 160 runs of the control loop so maintaining the original 100Hz update rate). This seems to have fixed it.
So a question - is there a good reason why the UpdateRotorFrequency() should be called from the scheduler thread?
I've no idea whether this issue is present in the F103 and have no real means of checking; it could be. On my setup the hiccup lasts for 10ms and is fairly slight, noticeable but only because the motor is running so smoothly. If it was hooked up to a gearbox I'm not sure whether it would be obvious. It's also fairly low rate, on my setup with a 16kHz interrupt rate it happens around once a minute, with the standard 8.8kHz rate I'd guess it would only be once every 2min. If anyone is running a bare motor with the standard F103 code I'd be very curious whether you do see/hear the occasional hiccup when running it (just a slight knock and a slight brief dip in speed).
Still running on the bench and still no hiccups
![Smile :-)](./images/smilies/icon_e_smile.png)
- johu
- Site Admin
- Posts: 5791
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 157 times
- Been thanked: 1025 times
- Contact:
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Interesting, should probably behave similar on the F1 and also on async machines.
Probably what happens is UpdateRotorFrequency() does its calculations, is then interrupted and when returning sets turnsSinceLastSample=0. Since the latter was increased by the PWM ISR that increase is now lost leading to a miscalculation of frequency on the next call. Frequency is used for syncadv, so it would be audible. The filtering probably keeps things in check but also prolongs the hiccup.
The main reason why it is called by the scheduler is because of the appropriate update rate. Of course it also works your way. I was always a bit reluctant to have code execute every n-th cycle because you might then under-estimate execution time of the ISR.
Probably what happens is UpdateRotorFrequency() does its calculations, is then interrupted and when returning sets turnsSinceLastSample=0. Since the latter was increased by the PWM ISR that increase is now lost leading to a miscalculation of frequency on the next call. Frequency is used for syncadv, so it would be audible. The filtering probably keeps things in check but also prolongs the hiccup.
The main reason why it is called by the scheduler is because of the appropriate update rate. Of course it also works your way. I was always a bit reluctant to have code execute every n-th cycle because you might then under-estimate execution time of the ISR.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
That was my first thought but it doesn't quite fit the data (it might be happening as well but would be a lot less noticeable than the one I'm capturing). On the one I'm looking at the frequency doesn't drop to zero or double it jumps from 20 to 1500, stays there for 10ms and then drops back to 20. I'm a little suspicious of the ABS macro, the define hides a bit of complexity and multiple reads of turnsSinceLastSample and if that went wrong it could have bigger consequences??johu wrote: ↑Sun May 21, 2023 6:10 pm Probably what happens is UpdateRotorFrequency() does its calculations, is then interrupted and when returning sets turnsSinceLastSample=0. Since the latter was increased by the PWM ISR that increase is now lost leading to a miscalculation of frequency on the next call. Frequency is used for syncadv, so it would be audible.
Not sure it really helps. In one of the plots above you can see the filtered data and all it does (once you allow for the logging overflow) is slow the edges slightly. I reckon the filter time constant is only around 1ms. This would equate to 2ms on the F103 code (my isr runs almost twice as often, need to remember to adjust the IIR filter to compensate). Compared to the 10ms update time it doesn't do that much. TBH you wouldn't want to slug it much more as 10ms is already slow enough to start to affect syncadv accuracy when the motor is accelerating quickly.
Agree completely but weighed against the simplicity of everything being in one thread I think simplicity wins. Plus it's only a dozen lines of fairly simple code so probably around 1/3us execution time on a F103 so shouldn't be a big source of error.
I'm also wondering whether to increase the rate the frequency update runs at to say 1kHz (every 1ms), that should fit nicely with the current filter time constant to give a quick but still smooth update. It could be a little problematic at lower motor speeds but I think it can be made to fairly efficiently and gradually revert to the current 10ms period (or even slower) as the motor slows down to maintain good low speed resolution too.
I'd still like to have fully diagnosed the problem (I hate fixing things without being able to fully explain all the symptoms) but there are other things that need doing more urgently!
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Something like this:Pete9008 wrote: ↑Sun May 21, 2023 6:48 pm I'm also wondering whether to increase the rate the frequency update runs at to say 1kHz (every 1ms), that should fit nicely with the current filter time constant to give a quick but still smooth update. It could be a little problematic at lower motor speeds but I think it can be made to fairly efficiently and gradually revert to the current 10ms period (or even slower) as the motor slows down to maintain good low speed resolution too.
Code: Select all
static uint32_t freqUpdateCount = 0;
static uint32_t stableCount = 1;
freqUpdateCount++;
if(freqUpdateCount >= (callingFrequency/FRQ_UPDATE_FRQ))
{
freqUpdateCount = 0;
distance += turnsSinceLastSample;
int absTurns = ABS(turnsSinceLastSample);
if (absTurns > STABLE_ANGLE)
{
lastFrequency = ((float)(FRQ_UPDATE_FRQ * absTurns)) / (float)(TWO_PI*stableCount);
detectedDirection = turnsSinceLastSample > 0 ? 1 : -1;
turnsSinceLastSample = 0;
stableCount = 1;
}
else
{
if(++stableCount > 20)
{
lastFrequency = 0.0f;
stableCount = 1;
}
}
}
Also just noticed there are a couple of divides in the above which will increase the execution time to say 1us on the F103??
Edit - became curious about execution time so plotted it for the F405. With the motor stationary (so running offset calibration) - 34.5-36%. With the motor running 30.75-31.25% with the occasional 32% (at around the right rate to be the frequency routine running). So that would mean the main control loop is running in around 19us with an extra 0.6us whenever the frequency update routine runs (and that's with debug optimisation level). Think I can live with that.
Interesting is that running in reverse consistently takes around 0.25% more cpu than running forward - not quite sure why
![Confused :?](./images/smilies/icon_e_confused.png)
Edit2 - Realised I could lose the (callingFrequency/FRQ_UPDATE_FRQ) divide by passing the value in instead (callingFrequency is actually a constant) which has knocked the delta down to around 0.3us.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
So I think the motor control processor is now working well enough to try on a full size motor (HSG only to date) but before that happens it makes sense to do the code for the STM32F103 that controls the boost converter and DC to DC while it's on the bench.
The plan for the DC to DC is to just have it running whenever the inverter is powered with the output set to a constant 13.5V. That should suit either a lead acid on float or a LiIon 12V battery. Let me know if anyone sees a problem with this?
The only issue is that the DC to DC is on the low voltage side of the boost converter which doesn't fit with the way I intend to use it (see later). The plan is to modify the resistors to suit higher voltage operation (as per the wiki) and then rewire the DC to DC supply so that it is fed straight off the HV bus bar. I still need to pull the base off the inverter to see how to do this. Based on pictures connections from the the bus bars do appear to go down to the lower section but appear to only be connected to a rectangular potted module labelled Panasonic. Does anyone know what this is? Could it be another capacitor?
The intention is to eventually have an extra battery pack in the front storage compartment of the Roadster. There isn't enough space for a full voltage pack there so the plan is to have something like 2 or 3 of the BMW PHEV modules giving 120V-180V. This would feed into the low voltage side of the buck/boost module. The buck/boost module would then be controlled to keep the front pack SOC equal to the main rear pack SOC (on average - both during charging and discharging).
The F103 also controls the contactors, coolant pump and fan so the code for them needs porting over too.
Edit - just thought to check the Oak Ridge report and the rectangular module is a capacitor. Probably best not to try to modify it to get access to the bus connections!
Edit2 - although it looks like it might be possible to run another copper strip connection down the side of it - need to pull it apart and have a proper look.
The plan for the DC to DC is to just have it running whenever the inverter is powered with the output set to a constant 13.5V. That should suit either a lead acid on float or a LiIon 12V battery. Let me know if anyone sees a problem with this?
The only issue is that the DC to DC is on the low voltage side of the boost converter which doesn't fit with the way I intend to use it (see later). The plan is to modify the resistors to suit higher voltage operation (as per the wiki) and then rewire the DC to DC supply so that it is fed straight off the HV bus bar. I still need to pull the base off the inverter to see how to do this. Based on pictures connections from the the bus bars do appear to go down to the lower section but appear to only be connected to a rectangular potted module labelled Panasonic. Does anyone know what this is? Could it be another capacitor?
The intention is to eventually have an extra battery pack in the front storage compartment of the Roadster. There isn't enough space for a full voltage pack there so the plan is to have something like 2 or 3 of the BMW PHEV modules giving 120V-180V. This would feed into the low voltage side of the buck/boost module. The buck/boost module would then be controlled to keep the front pack SOC equal to the main rear pack SOC (on average - both during charging and discharging).
The F103 also controls the contactors, coolant pump and fan so the code for them needs porting over too.
Edit - just thought to check the Oak Ridge report and the rectangular module is a capacitor. Probably best not to try to modify it to get access to the bus connections!
Edit2 - although it looks like it might be possible to run another copper strip connection down the side of it - need to pull it apart and have a proper look.
-
- Posts: 731
- Joined: Tue Oct 29, 2019 2:48 pm
- Location: France
- Has thanked: 329 times
- Been thanked: 44 times
- Contact:
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
What about selling those 2-3 modules and put 16 X lifePo4 mat modules @3.2v in the front. That way your HV is all the same and you add an additional bms.
On another subject, thanks for all the plots and codes, I learning lots from your work.
On another subject, thanks for all the plots and codes, I learning lots from your work.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
I haven't got the modules yet so more than happy to consider alternatives. Ideally after whatever provides the best energy density (lowest weight). Any more details on the lifePo4 cells?
Either way the front pack will have a separate BMS, contactors, voltage monitoring and current shunt.
The idea is that it will be removable from the car so for normal day to day use the pack stays home (and is used for energy storage) freeing up the front for luggage space. It's only fitted for longer runs. TBH I'll probably never get round to it but it makes sense to build in the inverter support for it now, just in case.
Edit - Thanks and I'm glad you're finding it interesting!
Either way the front pack will have a separate BMS, contactors, voltage monitoring and current shunt.
The idea is that it will be removable from the car so for normal day to day use the pack stays home (and is used for energy storage) freeing up the front for luggage space. It's only fitted for longer runs. TBH I'll probably never get round to it but it makes sense to build in the inverter support for it now, just in case.
Edit - Thanks and I'm glad you're finding it interesting!
- Bigpie
- Posts: 1595
- Joined: Wed Apr 10, 2019 8:11 pm
- Location: South Yorkshire, UK
- Has thanked: 75 times
- Been thanked: 304 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Extra pack via DCDC is pretty interesting, but I'd say overly complicated for what it's worth, what will it give, extra 15 miles? Unless it's for the fun of it.
Also, for me (my wife), taking longer trips seem to necessitate more stuff to come with.
Also, for me (my wife), taking longer trips seem to necessitate more stuff to come with.
VW Beetle 2003
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
Outlander front generator
Prius Gen 3 inverter (EVBMW logic board)
Outlander charger
3x Golf GTE batteries
Chademo Charging
Outlander water heater
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Bit of both really, it should be interesting to do and if I could get an extra 20-25 miles out of it might just be able to do day trips to the coast without needing to find a charger or use the ICE car
![Wink ;)](./images/smilies/icon_e_wink.png)
I'll probably never get round to doing the extra pack but the boost converter is already there and it would be nice to actually have it able to do something useful!
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Been curious about the deadtime setting on the Prius for a while so decided to measure it. Ideally the measurement would be made using a high freq current shunt on the DC bus supply (to measure the shoot though pulse amplitude) but I haven't got one so have just measured the DC bus supply current while adjusting the deadtime:
With the ideal deadtime there should be no overlap where both IGBTs being on, and so no shoot through but also no time where neither IGBT is conducting. In real life the actual value used has to be a bit of a compromise due to the shape of the IGBT switch off waveform (it has a bit of a tail).
The two points of interest are 1.6us (deadtime set to 130 in the web interface) and 1.8us (deadtime set to 140 in the web interface). 130, the default value for the Prius, looks about right.![Smile :)](./images/smilies/icon_e_smile.png)
Does anyone know how load current and heat affects the IGBT turn off tail? Does it get better or worse as load/heat goes up?
Edit - It seems the tail gets worse with increasing temperature so a slightly higher value for the deadtime may be beneficial. Will probably try 135 once the car is running to see if it drops the inverter temperature at all.
The line is a little shaky as I just used the bench PSU current which only has 10mA resolution bit I think it's good enough for now. It's also just a 32V supply - I'll redo the measurement once it's on a HV supply.With the ideal deadtime there should be no overlap where both IGBTs being on, and so no shoot through but also no time where neither IGBT is conducting. In real life the actual value used has to be a bit of a compromise due to the shape of the IGBT switch off waveform (it has a bit of a tail).
The two points of interest are 1.6us (deadtime set to 130 in the web interface) and 1.8us (deadtime set to 140 in the web interface). 130, the default value for the Prius, looks about right.
![Smile :)](./images/smilies/icon_e_smile.png)
Does anyone know how load current and heat affects the IGBT turn off tail? Does it get better or worse as load/heat goes up?
Edit - It seems the tail gets worse with increasing temperature so a slightly higher value for the deadtime may be beneficial. Will probably try 135 once the car is running to see if it drops the inverter temperature at all.
- janosch
- Posts: 307
- Joined: Tue Jun 30, 2020 9:23 am
- Location: London, UK
- Has thanked: 71 times
- Been thanked: 59 times
- Contact:
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Hello! Same same but different: Smart Roadster with I3 gear over here: viewtopic.php?p=56910#p56910
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Regen is now working ![Smile :)](./images/smilies/icon_e_smile.png)
Silly mistake on my part, I modified the throttle routines to accept three pots (redundant throttle plus brake) but forgot to increase the max index when normalising the pot positions. Now all sorted and seems to work well.
Think I'm now happy with the way the motor is running so can put the OI firmware to one side and start on other things.
![Smile :)](./images/smilies/icon_e_smile.png)
Silly mistake on my part, I modified the throttle routines to accept three pots (redundant throttle plus brake) but forgot to increase the max index when normalising the pot positions. Now all sorted and seems to work well.
Think I'm now happy with the way the motor is running so can put the OI firmware to one side and start on other things.
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Lol like mtpv
But seriously you’ve put so much into the firmware I expect your actual build is going to be just as thorough, not like some of us driving round with “temporary” wiring looms that just need tidying up!
But seriously you’ve put so much into the firmware I expect your actual build is going to be just as thorough, not like some of us driving round with “temporary” wiring looms that just need tidying up!
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Mtpv is still there but I've decided that I need data logging on the motor it's tested on, my gut feel is that it's likely to go unstable (with fairly abrupt consequences) and if it does I want the data to figure out what went wrong without having to risk repeating the test. At the moment my F405 build is the only one with working logging so the plan it to test it on that.
I have a habit of trying to do things right first time (my last build what was supposed to be a quick over winter engine swap and turned into a 5year full space frame chassis build!). Trying NOT to do that again but it goes against the grain for me. If I can convince myself that the first Roadster is more a test bed and then once I get it working I'll can transfer all the bits to a good one (mine is a little tired in places) then this one should hopefully progress quite quickly once I make it out to the workshop!
There is nothing about yours that I would call temporary - It's one of the nicest engineered conversions I've seen!
I have a habit of trying to do things right first time (my last build what was supposed to be a quick over winter engine swap and turned into a 5year full space frame chassis build!). Trying NOT to do that again but it goes against the grain for me. If I can convince myself that the first Roadster is more a test bed and then once I get it working I'll can transfer all the bits to a good one (mine is a little tired in places) then this one should hopefully progress quite quickly once I make it out to the workshop!
There is nothing about yours that I would call temporary - It's one of the nicest engineered conversions I've seen!
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Lol trust me there are temporary bits! Definitely some wiring to tidy! And the eBay electric oil pump that’s only rated to 20mins duty that’s done a year of service because it just keeps on working ,the replacement that I want to make is going to be driven off the diff flange! And is quite a project it’s self, but yes I do try to do things to a standard im happy to show people first time round, I wouldn’t want to show people if I was all rough cut bits of metal everywhere! People I know will happily build a track car like that all un painted steel brackets without so much as radiusing the corners with a flap wheel!
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Not sure these projects are ever really finished, there's always something being improved!
Trying to reign in my perfectionist tendencies on this one - not sure I'm doing too well though! I have a habit of spending so long on projects trying to get everything just right that by the time they are finished life has moved on and they are no longer as relevant as if they had been done a little bit less thoroughly at the start and then evolved while they were tidied up.
Trying to reign in my perfectionist tendencies on this one - not sure I'm doing too well though! I have a habit of spending so long on projects trying to get everything just right that by the time they are finished life has moved on and they are no longer as relevant as if they had been done a little bit less thoroughly at the start and then evolved while they were tidied up.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Just figured out how to make the SD card binary logging more usefull
Currently it logs all the critical control loop parameters on every run through the control loop. This is great for diagnosing control loop bugs (hopefully not many of these left now!) but not so useful for issues in the rest of the code. I had been thinking of adding a second mode that instead of logging binary data would send a command (stored in a file on the ESP32's flash file system) every 100ms and log the response. This would allow the user to decide what they wanted to log but it's one or the other, it wouldn't be possible to have control loop data logging and user configured logging.
Instead what I'm going to do is extend the binary logging functionality. The binary log already contains the full json parameter definition at the start of the file. It also contains an incrementing counter that is used to detect missing data packets. What I'm going to do is add one more byte to every packet, this will contain a quarter of a spot value parameter (8bits of the 32bits used to store each parameter). The parameter byte sent will increment on each packet, so the first 4 packets contain the first spot value, the next 4 the second spot value and so on. This will allow up to 64 spot value parameters to be sent indexed by the existing 8bit counter with a complete set being sent every 16ms. The PC decoding app will then use the count to put the bytes back together to get the parameter values and the json definition to associate them with the right name.
This approach logs the critical control loop data every at pass of the control loop (62us) plus all the spot value parameters at full resolution every 16ms, in essence everything that should be needed to figure out what was going on in the inverter if anything unexpected happens.
Edit - Hmm, that's a pain, in the json data the spot values don't have index values
Need to decide whether to just use the order they appear or whether to change the json format slightly to ad them (not keen on the later as it will break compatibility with F103 code although not that keen on the former either!)
Edit2 - Decoded to add a new json field for the spot index, all the spot values are now of the format:
Have added this to the STM code and done the basic decode and it seems to work fine. It also doesn't seem to break anything (web interface still seems happy). Next is to add the full spot value decode and generate a csv file. Should really also add some command line arguments so that the output file format (binary, spot or both) can be selected.
![Very Happy :D](./images/smilies/icon_e_biggrin.png)
Currently it logs all the critical control loop parameters on every run through the control loop. This is great for diagnosing control loop bugs (hopefully not many of these left now!) but not so useful for issues in the rest of the code. I had been thinking of adding a second mode that instead of logging binary data would send a command (stored in a file on the ESP32's flash file system) every 100ms and log the response. This would allow the user to decide what they wanted to log but it's one or the other, it wouldn't be possible to have control loop data logging and user configured logging.
Instead what I'm going to do is extend the binary logging functionality. The binary log already contains the full json parameter definition at the start of the file. It also contains an incrementing counter that is used to detect missing data packets. What I'm going to do is add one more byte to every packet, this will contain a quarter of a spot value parameter (8bits of the 32bits used to store each parameter). The parameter byte sent will increment on each packet, so the first 4 packets contain the first spot value, the next 4 the second spot value and so on. This will allow up to 64 spot value parameters to be sent indexed by the existing 8bit counter with a complete set being sent every 16ms. The PC decoding app will then use the count to put the bytes back together to get the parameter values and the json definition to associate them with the right name.
This approach logs the critical control loop data every at pass of the control loop (62us) plus all the spot value parameters at full resolution every 16ms, in essence everything that should be needed to figure out what was going on in the inverter if anything unexpected happens.
Edit - Hmm, that's a pain, in the json data the spot values don't have index values
![Sad :(](./images/smilies/icon_e_sad.png)
Edit2 - Decoded to add a new json field for the spot index, all the spot values are now of the format:
Code: Select all
"udc": {"unit":"V","value":0.00,"isparam":false,"si":6},
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
The logging with combined binary data and sport values is now working and the results look pretty good. The data is logged to the card whenever the inverter is running and there is no wifi connection to the ESP32. The file can then be copied off the SD card and decoded using a PC app. It generates two csv files, one for the control loop data and one for the spot values.
The control loop data looks like this and contains a line every 62.5us:
While the spot value data looks like this and contains a line every 16ms:
Both can be imported straight into a spreadsheet to allow the data to be plotted, for example a couple of graphs generated from the spot values on a 1min test run:
The control loop data can also be analysed in a spreadsheet but the files are large so it is pretty slow. The plan was to use PulseView to analyse them (see the logging thread for more details) but there is a problem. This is what's plotted:
The problem is most obvious on il1 and il2 and is most easily seen in the highlighted area, the motor is actually stationary here! Plotting the same data file using gnuplot gives:
Which is what il1 should look like. Looks like PulseView may not be able to cope with these files ![Sad :(](./images/smilies/icon_e_sad.png)
Have tried a few things to fix it but so far no luck so now looking for another application to use for analysis.
Happy with the SD card logging now anyway.
The control loop data looks like this and contains a line every 62.5us:
Code: Select all
Time (s),count,angle,frq,i1,i2,pwm1,opmode,pwm2,desat,pwm3,iqref,idref,ifw,uq,ud,spot,csum,iq,id,
0,39,346.25,0,0.25,0,-0.685714,1,-0.304762,0,0.666667,0,0,0,-0.595155,-0.377286,0,58,0.199621,0.20853,
6.25e-05,40,346.25,0,0,0,-0.495238,1,-0.304762,0,0.47619,0,0,0,-0.45168,-0.233811,4,101,0,0,
0.000125,41,346.25,0,0,0,-0.380952,1,-0.304762,0,0.361905,0,0,0,-0.3826,-0.159417,0,125,0,0,
0.0001875,42,346.25,0,0,0,-0.285714,1,-0.285714,0,0.266667,0,0,0,-0.313519,-0.0850222,0,154,0,0,
0.00025,43,346.25,0,0,0,-0.342857,1,-0.152381,0,0.32381,0,0,0,-0.281636,-0.180672,0,150,0,0,
0.0003125,44,346.25,0,-0.25,-0.25,0.47619,1,0.685714,0,-0.685714,0,0,0,0.733317,0.111592,242,144,-0.480024,-0.139918,
Code: Select all
Time (s),opmode,lasterr,status,pwmmax,pwmirqfrq,udc,idc,il1,il2,id,iq,ifw,ud,uq,fstat,speed,cruisespeed,amp,angle,pot,pot2,regen,potnom,dir,tmphs,tmpm,uaux,pwmio,canio,testangle,din_start,din_brake,din_forward,din_reverse,cpuload,
0.0295625,1,13,0,10500,16000,32,0,-0.34375,0.03125,-0.21875,-0.375,0,32.5,-319.656,0,0,-1,514.969,346.219,22,23,23,0,0,20,299,0,0,0,0,0,0,0,0,34.1875,
0.0455625,1,13,0,10500,16000,32,0,0,0.1875,-0.125,-0.46875,0,-87.7188,240.875,0,0,-1,185.531,346.219,22,23,23,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
0.0615625,1,13,0,10500,16000,32,0,0,0.09375,-0.15625,0.375,0,-25.7188,-141.313,0,0,-1,445.75,346.219,23,23,23,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
0.0775625,1,13,0,10500,16000,32,0,-0.1875,0.0625,0.125,0.09375,0,-173.688,461.938,0,0,-1,90.3125,346.219,22,23,22,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
0.0935625,1,13,0,10500,16000,32,0,0.09375,0.28125,0.125,0.375,0,-34.2188,-178.406,0,0,-1,125.063,346.219,23,23,22,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
0.109562,1,13,0,10500,16000,32,0,0.03125,0.125,0.0625,-0.125,0,104.563,-114.344,0,0,-1,548.75,346.219,23,23,23,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
0.125562,1,13,0,10500,16000,32,0,0.25,-0.5,0,-0.125,0,36.6875,-208.063,0,0,-1,56.25,346.219,22,23,22,0,0,20,299,0,0,0,0,0,0,0,0,38.2813,
![Sad :(](./images/smilies/icon_e_sad.png)
Have tried a few things to fix it but so far no luck so now looking for another application to use for analysis.
Happy with the SD card logging now anyway.
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
It look like it is the PulseView CSV import that's the problem. This is what it looks like when exported directly to PulseView format:
![Smile :)](./images/smilies/icon_e_smile.png)
It's still a bit hacky, and I'm having to manually create the metadata file and zip up all the data to create the PulseView file but it proves the principle. Fairly sure this has been an issue from the start, the data is much, much cleaner now. This is what a zoomed in section looks like: It has the added advantage that the csv file for a minute of data was 90MB, the same data in PulseView format is only 12MB.
Happy with that, will tidy up the code and get it to automatically create the complete file later in the week.
The only issue is that it does show how much the FW is limiting the available iq - need to have another look at that!
Edit - Not sure it is the FW limiting iq - something isn't right there, definitely need to have another look through the code.
Edit2 - Think it might be running out of control loop gain. This is a high inductance motor so would already need high gains but it's also only running at 30V so needs the gains to be around 10x higher than normal to compensate for the low volts. Will try increasing them a bit more but will probably have to rebuild the code first to increase the maximums on the ki and kp parameters.
The data has been read in perfectly ![Smile :)](./images/smilies/icon_e_smile.png)
It's still a bit hacky, and I'm having to manually create the metadata file and zip up all the data to create the PulseView file but it proves the principle. Fairly sure this has been an issue from the start, the data is much, much cleaner now. This is what a zoomed in section looks like: It has the added advantage that the csv file for a minute of data was 90MB, the same data in PulseView format is only 12MB.
Happy with that, will tidy up the code and get it to automatically create the complete file later in the week.
The only issue is that it does show how much the FW is limiting the available iq - need to have another look at that!
Edit - Not sure it is the FW limiting iq - something isn't right there, definitely need to have another look through the code.
Edit2 - Think it might be running out of control loop gain. This is a high inductance motor so would already need high gains but it's also only running at 30V so needs the gains to be around 10x higher than normal to compensate for the low volts. Will try increasing them a bit more but will probably have to rebuild the code first to increase the maximums on the ki and kp parameters.
-
- Posts: 731
- Joined: Tue Oct 29, 2019 2:48 pm
- Location: France
- Has thanked: 329 times
- Been thanked: 44 times
- Contact:
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Wow pete, you really get around a pc!! Thanks for all the efforts. You're adding some serious benefits for diagnostics to the OI solution. Bravo ![👏](//cdn.jsdelivr.net/gh/twitter/twemoji@latest/assets/svg/1f44f.svg)
-
- Posts: 1801
- Joined: Sun Apr 03, 2022 1:57 pm
- Has thanked: 102 times
- Been thanked: 347 times
Re: Smart Roadster (with Prius Gen3 Inverter and Outlander Rear Motor)
Thanks!
That's exactly what the aim is - it's sooo much easier diagnosing problems or understanding operation when all the data is available!
That's exactly what the aim is - it's sooo much easier diagnosing problems or understanding operation when all the data is available!