Lincoln MKZ / Ford Fusion compatibility #1
Comments
|
First thing seems to be to create a file like this one:
|
|
Found one here: https://bitbucket.org/DataspeedInc/dbw_mkz_ros/downloads |
ingenieroariel
referenced
this issue
in autti/openpilot
Nov 30, 2016
espes
added a commit
that referenced
this issue
Nov 30, 2016
Ford Fusion 2017 dbc can file. refs #1.
|
That dbc's not correct for production cars, just (i assume) dataspeed's |
|
Unfortunately yes, only dataspeed. |
|
I have a Ford Fusion 2017 myself and will debug further next week when my oneplus three arrives. |
|
That dbc file won't work at all. It defines the message formats on a private CAN bus run by dataspeed. Dataspeed, as far as I know, controls the vehicle via some electromechanical methods, not just CAN codes. A node on the private CAN bus translates these messages to actual electrical signals. My guess is that the throttle is handled by controlling a voltage, but I'm not sure. |
ingenieroariel
referenced
this issue
in autti/openpilot
Dec 1, 2016
|
According to the following spreadsheet [1] available from the OpenXC website here is the information we can find on CAN1 [OBD-II pins steering_wheel_angle [1] https://docs.google.com/spreadsheets/d/1hOBi9-tFwR1KRFXfeaHTAddwJuSGx5Ir1ET4N2zWAiE/edit#gid=6 |
|
For people trying to help solve this issue @geohot recommended the following document: http://www.ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdf I personally recommend to get an OpenXC adapter from Ford instead of trying to build the NEO can adapter. I got the FORD REFERENCE VI for $130 usd at https://shop.openxcplatform.com |
|
okay, I've been able to read data from the car via bluetooth and USB. So far I have only been able to get data in JSON format, but I plan to see if I can create a raw CAN dump using the kvaser leaf light. Once I have a raw dump with the corresponding JSON dump I'll share it here.
https://gist.github.com/ingenieroariel/ff1f4cac30e1bc5ec22f72967b1d2866 |
|
Here is a sample data dump from a regular ford fusion when idle. It'll be useful later when comparing with the data dump from can bus 1 after cruise control is enabled. |
|
Here is a full can dump with park assist activated: If anyone wants to help me out identify what is what, be my guest. My next target is finding a can bus directly on the front camera. PS: Not sure what the right etiquette for this project is, if I am spamming too much please let me know and I'll do less frequent updates. |
|
You reckon this the same system for all ford vehicles. I could try this in a focus |
|
|
|
Okay, after cutting the wires from the canbus that went to the camera I was able to write a few packets that changed the left arrow keys on my wheel control. When connecting the camera again I got the following id codes that are potentially related to LKAS and collision assist.
I'll collect data from just those 3 codes on a longer ride today. Is anyone interested in helping me decode them? Here is a sample in SocketCan format: |
|
BTW, here is a list of all the packet ids that are NOT coming from the front camera:
|
|
I may be wrong but here is what I think based on enabling LKAS on the road. This message may mean LKAS is enabled but no lane has been found:
In this frame LKAS found me drifting away from my lane and trying to get me back on track. |
|
What the latest update? |
|
I figured out for ACC which frames report the steering wheel buttons are pressed (0x91) and the one that reports ACC being enabled, the brake or gas peal being pressed and which speed the ACC is set to (0x165). For LKAS this one reports if it is on or not (0x3d8) and also seems to report info from other sensors, but I need to wait until I drive with a sidekick to learn more. The only frame I have been able to spoof is (0x82) to interact with the arrow buttons on the steering wheel. Will keep at it and report back. I am doing all this with an openxc adapter spitting out raw can encoded as JSON conected to my Macbook 12". There are several ways I can use to get data faster:
|
|
if you have a kvaser interface why are you still using the open-xc interface ? Option number 5 is probably your best bet for reverse engineering you can't afford more expensive tools. |
|
It has been mainly logistics. Socketcan does not work on OSX and that's the only laptop I own. I'll install linux on my laptop and try to get the kvaser working this week, thanks for the hint. When I first tried it I could not get |
|
From what I've seen ford supports the OpenXC adaptor |
|
@geohot Have you thought about hiring yourself/team out for a fee? In the case of some members on github suggesting to fly people out |
|
We are open to people funding ports |
|
I've been a little hesitant to post about can bus codes, but here goes. I also have a Ford Fusion. It's a 2013. It has the parking assist and lane keep assist.
|
|
That connector is for the lane keep assist camera. |
DrFritzi
pushed a commit
to DrFritzi/openpilotOld
that referenced
this issue
Feb 14, 2021
gwillmer
pushed a commit
to gwillmer/openpilot
that referenced
this issue
May 13, 2021
works on 2017 Gas Chrysler Pacifica
SebastienLubrano
pushed a commit
to SebastienLubrano/openpilot
that referenced
this issue
Jul 8, 2021
Toyota fw update
robin-reckmann
referenced
this issue
in robin-reckmann/openpilot
Aug 10, 2021
add fw versions for 2018 Nissan Leaf JP
ClockeNessMnstr
referenced
this issue
in ClockeNessMnstr/openpilot
Aug 29, 2021
* (+cereal) Discrete PIDFF * Back-Calculate PID output * report actual output per vehicle * PID Cleanup * Forester 30 step * Use EPS torque to backfeed integrator * (+cereal) Backfeed Stock LKAS/ALC * Reverse alc contribution * set saturation on pid clipping only * add Stock feedback weights * bump cereal + panda
GregorKikelj
pushed a commit
to GregorKikelj/openpilot
that referenced
this issue
Dec 28, 2021
Edison-CBS
pushed a commit
to Edison-CBS/openpilot
that referenced
this issue
Apr 24, 2022
haraschax
pushed a commit
that referenced
this issue
Jun 7, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify #1
mmmorks
pushed a commit
to mmmorks/openpilot
that referenced
this issue
Jun 14, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify commaai#1
mmmorks
pushed a commit
to mmmorks/openpilot
that referenced
this issue
Jun 15, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify commaai#1 (cherry picked from commit b215d61)
ntegan1
referenced
this issue
in ntegan1/apilot
Jun 16, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify #1
rjsmith1999
pushed a commit
to rjsmith1999/openpilot
that referenced
this issue
Jun 27, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify commaai#1
rjsmith1999
added a commit
to rjsmith1999/openpilot
that referenced
this issue
Jun 27, 2022
commit d066702 Author: ClockeNessMnstr <locke.dftc@gmail.com> Date: Tue Jun 7 12:41:03 2022 -0400 update DH names + notes for MPC output curvatures (commaai#24701) * update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify commaai#1 commit cb82478 Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Fri May 27 10:21:02 2022 -0700 Tssp prius torque control (commaai#24669) * use llk * use steering sensor at low speed stil * Try more simple * rm prius tune * updated ref commit f1f7a0b Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Tue May 24 17:52:33 2022 -0700 Rerevert torque control (commaai#24649) * Revert "Revert torque control (commaai#24565)" This reverts commit 9f8b037. * Move tune out of car specific stuff * Update ref commit commit 041c255 Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Tue May 17 19:00:57 2022 -0700 Revert torque control (commaai#24565) * torque reversal start * Fix carmodel tests * Update ref * update ref * Elif is better than if commit 14f5dab Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Fri May 20 13:50:47 2022 -0700 Latcontrol torque: integrator need not be reset (commaai#24606) slow integrators need not be reset commit 9221f3f Author: ClockeNessMnstr <locke.dftc@gmail.com> Date: Fri May 13 19:52:20 2022 -0400 LatControlTorque: clean up class variable (commaai#24526) * move to super * no class variable * there's CP * whitespace * drop CI from latcontrol super * Revert "drop CI from latcontrol super" This reverts commit 9218273. Co-authored-by: Shane Smiskol <shane@smiskol.com> commit efb4dbd Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Fri May 6 22:17:21 2022 -0700 Latcontrol torque: fix integrator induced ping pong (commaai#24458) * Latcontrol torque: fix integrator induced ping pong * Reset on disengage since unwind resets anywayh * Might be overkill * rm whitespace * update ref commit d105ae2 Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Mon May 2 14:42:18 2022 -0700 Latcontrol torque: update tuning (commaai#24357) * Little more chill * Update ref * Update refs commit 0ce2b58 Author: Shane Smiskol <shane@smiskol.com> Date: Thu Apr 28 00:42:52 2022 -0700 Clean up controllers (commaai#24340) * clean up lat controllers * pass CP once * sort commit 47b162c Author: Shane Smiskol <shane@smiskol.com> Date: Wed Apr 27 01:18:05 2022 -0700 LatControlTorque: fix deadzone and missing steer saturated warning (commaai#24294) * fix steer saturated alert and deadzone * fix and formatting * update refs * update refs * not needed * remove commit 51a7ef2 Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Wed Apr 20 11:26:24 2022 -0700 Latcontrol torque: max_torque rename (commaai#24265) commit 33e00f6 Author: HaraldSchafer <harald.the.engineer@gmail.com> Date: Tue Apr 19 19:34:31 2022 -0700 Lateral torque-based control with roll on TSS2 corolla and TSSP rav4 (commaai#24260) * Initial commit * Fix bugs * Need more torque rate * Cleanup cray cray control * Write nicely * Chiiil * Not relevant for cray cray control * Do some logging * Seems like it has more torque than I thought * Bit more feedforward * Tune change * Retune * Retune * Little more chill * Add coroll * Add corolla * Give craycray a good name * Update to proper logging * D to the PI * Should be in radians * Add d * Start oscillations * Add D term * Only change torque rate limits for new tune * Add d logging * Should be enough * Wrong sign in D * Downtune a little * Needed to prevent faults * Add lqr rav4 to tune * Try derivative again * Data based retune * Data based retune * add friction compensation * Doesnt need too much P with friction comp * remove lqr * Remove kd * Fix tests * fix tests * Too much error * Get roll induced error under 1cm/deg * Too much jitter * Do roll comp * Add ki * Final update * Update refs * Cleanup latcontrol_torque a little more
ntegan1
referenced
this issue
in ntegan1/apilot
Jul 12, 2022
* update names + notes for MPC outputs "current_curvature" is not the correct description of what the MPC is outputting in it's curvature_ego state. The MPC is integrating it's free variable, curvature_rate, such that curvature[0] is actually the desired_curvature before any delay. inversely: the curvature_rate_desired is the desired rate of change to the setpoint and not the actual curvature rate. If we were to set the initial curvature = measured curvature in the MPC initiation these names would be correct. This was possibly how it was initially set up but the nomenclature here is now confusing. * more notes * match * Clarify #1
jbschooley
pushed a commit
to jbschooley/openpilot
that referenced
this issue
Jul 14, 2022
infiniteCable
added a commit
to infiniteCable/openpilot
that referenced
this issue
Mar 7, 2024
…f disabled steering centering commaai#1
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Udacity is also building a self driving car using that model as a reference.
What is the list of things to take into account to port openpilot to other cars?
Here is a list based on what I have read so far:
The text was updated successfully, but these errors were encountered: