Ford CANFD Radar Parser #1835
Ford CANFD Radar Parser #1835
Conversation
opendbc/car/ford/interface.py
Outdated
| @@ -34,6 +34,10 @@ def _get_params(ret: structs.CarParams, candidate, fingerprint, car_fw, experime | |||
| # MRR_Header_Timestamps->CAN_DET_TIME_SINCE_MEAS reports 61.3 ms | |||
| ret.radarDelay = 0.06 | |||
|
|
|||
| if not ret.radarUnavailable and DBC[candidate][Bus.radar] == RADAR.DELPHI_MRR_64: | |||
There was a problem hiding this comment.
Didn't really understood how the 60ms was calculated, but I tried to apply a similar logic for CANFD
| azimuth = msg[f"CAN_DET_AZIMUTH_{ii:02d}_{iii:02d}"] # rad [-3.1416|3.13964] | ||
| distRate = msg[f"CAN_DET_RANGE_RATE_{ii:02d}_{iii:02d}"] # m/s [-128|127.984] | ||
| dRel = cos(azimuth) * dist # m from front of car | ||
| 8000 | yRel = sin(azimuth) * dist # in car frame's y axis, right is positive |
There was a problem hiding this comment.
This is the major change between CAN and CANFD, I can't say if it's correct not not the one for CAN, but this one makes the most sense for CANFD. See the PR details for more explanation
|
🚀 |
|
This PR has had no activity for 60 days. It will be automatically closed in 7 days if there is no activity. |
|
|
||
| # Update once we've cycled through all 4 scan modes | ||
| if headerScanIndex != 3: | ||
| return True, [] # MRR_Detection_* messages in CANFD are at 20Hz, services.py expects liveTracks to be at 20Hz - we'll send messages to meet the 20Hz |
There was a problem hiding this comment.
CANFD MRR is at 20MHz
liveTracks is at 20Hz in services.py - https://github.com/commaai/openpilot/blob/master/cereal/services.py#L33
Sending for 2 scans out of 4 does not mark liveTracks as invalid, but sporadically some liveTracks don't make it to radard which causes radard alerts - since it's marked as invalid as well.
There was a problem hiding this comment.
Is this even needed for CAN FD? This was only for clustering since the track IDs didn't match positionally that well, and radard requires consistent tracks in time
There was a problem hiding this comment.
So, based on what you said, I should track how a track changes over time. I should check how its position shifts from one frame to the next, how smooth the graph of the track is. Is this right?
My understanding was that you didn't want to over load the system with multiple clustering.
I'll graph the tracks and see how they change over time.
There was a problem hiding this comment.
No, the clustering here isn't very clean and should ideally go into radard. If we can avoid another platform that uses it in the meantime, that's better.
|
Gonna merge, then we can do final validation once we use it for OP long. For now, it'll only affect FCW. |
|
|
||
| # average of 20 Hz radar timestep / 4 scan modes = 100 ms | ||
| RADAR.DELPHI_MRR_64: 0.1 | ||
| }.get(Bus.radar, 0.1) |
There was a problem hiding this comment.
just use an if statement, dict.get never looks clean
There was a problem hiding this comment.
you're comparing an auto enum against a set of unrelated strings
There was a problem hiding this comment.
I'll bring back the if statements in a clean way.
|
|
||
| # Update once we've cycled through all 4 scan modes | ||
| if headerScanIndex != 3: | ||
| return True, [] # MRR_Detection_* messages in CANFD are at 20Hz, services.py expects liveTracks to be at 20Hz - we'll send messages to meet the 20Hz |
There was a problem hiding this comment.
So, based on what you said, I should track how a track changes over time. I should check how its position shifts from one frame to the next, how smooth the graph of the track is. Is this right?
My understanding was that you didn't want to over load the system with multiple clustering.
I'll graph the tracks and see how they change over time.
|
|
||
| # average of 20 Hz radar timestep / 4 scan modes = 100 ms | ||
| RADAR.DELPHI_MRR_64: 0.1 | ||
| }.get(Bus.radar, 0.1) |
There was a problem hiding this comment.
I'll bring back the if statements in a clean way.
Make sure you understand what each is |
|
Can you provide a route? The two in the description don't have rlogs |
I'm guessing the old routes were archived. These are routes on a clean master: All 4 routes have empty GitDiff. See if they help. |
Radar enabled with the same logic as for CAN - see below for more details:
Radar Enabled - with final version of the code:
I started with using the same logic used for CAN Fords, adjusting the code for the missing signals in CANFD, and I had some artifacts like:
https://github.com/user-attachments/assets/f4537216-9a6d-43a3-b973-a7bca28b8ff9
Check the lead chevron how it bounces.
https://github.com/user-attachments/assets/dfd9ff2a-e680-4d3f-afd5-2f34bd463ee9
I'm expecting the old radar points to remain in the right and new ones to come on the left.
The road curves to the right and the radar points cross the lanes, when there is noting on the lanes.
CAN logic uses
yRel = -sin(azimuth) * distand I used the same for CANFD and I got the above artifacts, then I switched toyRel = sin(azimuth) * distand I got:AdjustedRadar-small.mp4
Note how nice old points are left on the right and new ones come from the left.
https://github.com/user-attachments/assets/d2120681-f914-4c7c-b338-2d0f11cf1e35
Note how nice the radar points match with the left edge of the road.
I will add some more comments in the code.