always get zero for observation.ego_vehicle_state.yaw_rate
See original GitHub issueWhile trying to calculate actions for expert data, I find that observation.ego_vehicle_state.yaw_rate
always return 0.0
.
This is my agent interface, and I think the required sensors have been opened.
interface = AgentInterface(
done_criteria=done_criteria,
max_episode_steps=None,
waypoints=True,
neighborhood_vehicles=True,
ogm=False,
rgb=False,
lidar=False,
action=ActionSpaceType.Imitation,
)
Issue Analytics
- State:
- Created a year ago
- Comments:8 (3 by maintainers)
Top Results From Across the Web
Joint Radar Alignment and Odometry Calibration
Even on a straight road, non-zero yaw rates are measured due to sensor noise. If the measurements are not independent, but anyhow correlated...
Read more >Research on Target Tracking Algorithm Using Millimeter ...
The radar target tracking algorithm gets the lateral distance between the ... is the observation noise of yaw rate sensor, and , and...
Read more >Motion prediction of ego vehicle in complex scenarios
The aim of this thesis is to find a predicted trajectory of the ego vehicle. The ego vehicle forward speeds and yaw-rates are...
Read more >Tracking and Estimation of Ego-Vehicle's States for Lateral ...
researchers, with an eye on cheaper costs and installation flexibility, have studied vi- sion sensor usages. In this paper, we presents an ...
Read more >Passive Sensor Integration for Vehicle Self-Localization in ...
This research proposes an accurate vehicular positioning system which can achieve lane-level performance in urban canyons.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes, we will do that before its included in a release. (We normally merge first into
develop
, then upon release, intomaster
.)However, the
smarts_traffic
branch cannot yet be merged intodevelop
since it is a “breaking change” requiring a full version bump (to version0.7
from version0.6
) instead of an incremental change (which would go from, for example,0.6.1
to0.6.2
). Oncesmarts_traffic
is merged intodevelop
, the next release must be0.7
.The reason I did this fix on the
smart_traffic
branch first is because it is somewhat easier and cleaner there, since this branch includes a major refactor to how we handle Providers, and this particular bug relates to that. But the fix can also be made in a separate PR that gets merged intodevelop
sooner, although it may not be as clean there. I’m willing to do so if it seems like version0.7
will be delayed for a while.The fix for this has now been merged into
develop
.