[DRAFT] AMK Motors (the car will move soon) #137
Conversation
…rol, which will require free CAN config
…nit stuff to match
…ing off the motors
…its okay for now, still not 100% sure on exactly what temps and stuff we need
…it works but its all there, atleast the stuff I know that needs to be there :) Except for wheel speeds
…I have here is good enough? Or can I just set them to max values and just set torque setpoint normally from there?
… they want me to send with 1% scaling
common/amk/amk.h
Outdated
| uint16_t AMK_bError : 1; | ||
| uint16_t AMK_bWarn : 1; | ||
| uint16_t AMK_bQuitDcOn : 1; | ||
| uint16_t AMK_bDcOn : 1; /* Same as QUE ?? */ |
There was a problem hiding this comment.
Have you verified this yet?
There was a problem hiding this comment.
I am still looking into this. I am unsure if this is even necessary. We can charge the caps and monitor the DC bus voltage ourselves, correct? Or I would think once the precharging on our side is complete, we should be good to go. But that is a Finn question I would think.
common/amk/amk.c
Outdated
| SEND_AMK_TESTING(motor->states.init_stage, motor->control.bits, motor->status.bits, *motor->pchg_complete); | ||
| } | ||
|
|
||
| /* TODO: Determine period of this. Should be pretty often of course. The control |
There was a problem hiding this comment.
Have you explored this more? Talk to Demetrius if you need to
common/amk/amk.c
Outdated
| motor->torque_limit_positive = 0; | ||
| } else { | ||
| /* FIXME: Was told 9.8Nm is nominal, and to set to limit to 17Nm for now, | ||
| * but in the mean time I am going to go less than 100% as I am unsure */ |
There was a problem hiding this comment.
Not as of now, I have talked with Demetrius and he still isn't fully sure. I am working on figuring this out though. I think we are going to keep the limits fairly low to start just to make sure all is good
There was a problem hiding this comment.
Make sure this is resolved and delete the comments in the code.
There was a problem hiding this comment.
Overall looks good, I was quite nitpicky lol. I have a couple overall things that I will mention here:
- I think we should wait until entering ready to drive to enable the AMKs, and disable them upon exiting ready to drive. That way there is no chance we accidentally send anything to them. We also have a 1 second grace period to do this because of the required 1s buzzer sound. We can then deinit the amks when exiting ready to drive.
- Do you know how the AMKs will react if power is pulled without deactivating them? For example what if we are in ready to drive and someone just turns off HV? Will we have enough time to deactivate the AMKs given the state machine has been carried out incorrectly? This is probably a non issue because we will have carried out the deinit process well before we get under the minimum voltage of the AMKs while discharging but I thought I'd bring attention to it.
- You aren't fully handling left vs. right. I left a comment about this so just take a look at that. But right now we will only ever be able to control 1 amk at a time which is fine for testing purposes but if this PR is to merge we need both.
- Also quick reminder to remove all the commented code/questions or notes that are no longer relevant, not a big deal cuz this is a draft pr
VERY IMPORTANT NOTE POST AMK TRAINING:
You do not need to send these signals for energizing in a sequence. You can send them all together. This will drastically simplify your state machine. We don't need a state machine to enable/disable. Just make sure pre-charging is complete and set + clear all three bits at the same time.
| #endif // _PHAL_CAN_H |
common/amk/amk.c
Outdated
| case MOTOR_DEINIT_PRECHARGE: | ||
| /* 7. Discharge DC caps; QUE should be reset (is this just DcOn?) */ | ||
|
|
||
| /* FIXME: Will this work? Not sure if this goes low when discharged */ | ||
| if (!(*motor->pchg_complete)) { | ||
| motor->states.init_stage = MOTOR_DEINIT_POWER_OFF; | ||
| } | ||
|
|
||
| /* If discharged, move on */ | ||
| motor->states.deinit_stage = MOTOR_DEINIT_POWER_OFF; | ||
|
|
||
| break; | ||
| case MOTOR_DEINIT_POWER_OFF: | ||
| /* 8. Turn off 24v DC to inverters */ | ||
| /* We don't do much here, just have to turn off the car I guess */ | ||
| motor->states.deinit_stage = MOTOR_DEINIT_DONE; | ||
| motor->states.stage = MOTOR_STAGE_OFF; | ||
|
|
||
| break; | ||
| } |
There was a problem hiding this comment.
I don't think we care about discharging the vehicle here. All we care about is that we are turning off the AMKs. As such I think we can latch into a DEINIT_DONE state that gets reset in the main state machine when we either exit the deinit state or enter the init state. Also, there is no path to enter this state right now. We will just turn the car off in the RUNNING state. I think we should honestly move to gating this init/deinit behavior on the vehicle entering ready to drive. We should of course keep all of the precharge checks. When we aren't in ready to drive we absolutely don't want torque being sent to the motors anyway.
common/amk/amk.c
Outdated
| if (motor->status.fields.AMK_bSystemReady) { | ||
| motor->states.reset_state = MOTOR_RESET_INVERTER_OFF; | ||
| motor->states.running_stage = MOTOR_RUNNING_GOOD; | ||
| } |
There was a problem hiding this comment.
We should implement retry behavior (with a limit on number of retries that either sets an error/fatal fault). Also do you know how long we need to remain in each of these states? Will the AMK respond effectively if we follow our own timing and just enter each state once?
There was a problem hiding this comment.
Update on this comment, after watching the AMK training, we should expect the AMK to register our change within 1-2ms of receiving our message over CAN. So this should be fine as is, but we should look out for this in the event this actually happens while driving @mcgalliard
… the whole large state machine for init and deinit
…eck something before finishing even in this simplified system
I am working on setting up all motor can message (Free CAN) and getting the init and deinit state machine setup. Then will move on calling motors functions in car.c.
Seth is working on getting CAN2 working with our current CAN setup (different branch)