Hello, I have some questions regarding the use of the SparkFun ZED-F9R in dead reckoning mode for indoor use.
I have the SparkFun ZED-F9R in dead reckoning mode as a rover station, connected to a RTK base station with RTK float and fix corrections. After calibration according to the manual, it is now in dead reckoning mode, and the status is 3D + DR/Fixed or Float in fusion mode. However, I do not have a wheel tick sensor.
1. When using it indoors (stationary in a parking lot), the position is not accurate and does not stay fixed(Lat Lon is not stable). Should I install a wheel tick sensor? If so, can I just connect it to W+ and W-, and will the program automatically calibrate (single wheel tick)? Can you recommend a suitable model?
2. Is it possible to use the SparkFun ZED-F9R in dead reckoning mode indoors with high accuracy, in combination with an RTK base station, the built-in IMU of the F9R, and a wheel tick sensor?
I can confirm that without wheel tick on car, it is not very precise when driving indoor. It is not so bad inside tunnel at stabilized speed. It is worth in covered parking.
When connecting a wheel tick encoder to the SparkFun F9R, does the algorithm automatically calculate the position based on the calibration? And in the UBX-ESF menu, will the single wheel tick sensor display as calibrated? Also, when the car stops indoors, will the position continue to shift? Thank you for your answer.
The wheel tick data is used in combination with the other sensor inputs, all of which have different prominant noise properties, ie dither, drift, etc
When the wheels stop ticking it’s probably NOT moving, unless say on a ferry or train.
You also don’t need physical pins, you can push in speed or ticks via software methods.
And, for example, ticks from both rear wheels.
Also setting up the relative geometries of the receiver, antenna, and turning center, etc.
For these things to work effectively you need to integrate them rather than slap-dash the implementation.
I am using the ESP32 and SparkFun F9R. The software method involves receiving the speed data from the SparkFun F9R, along with the wheel size, etc., to calculate the estimated ticks. I then send the calculated value back from the ESP32 to the SparkFun F9R to be used in combination with other sensor data (IMU, GNSS, and estimated ticks). Is that correct?
The Speed can be sent in SI units
The Ticks are more arbitary units, which you can either define, or the receiver can determine during the fusion process.
Ticks can come from encoders, or motor drive subsystem.
I am seeing much better dead reckoning performance with the uBlox M8L vs M8U via use of left/right wheel speeds on both OBD2 and J1939 vehicles. I suspect the F9 modules use a similar DR technique. See the typ performance of an M8L on a light duty OBD2 vehicle using rear wheel speeds. Thanks.
I have additional questions regarding using OBD2. Do you have a wiring diagram for connecting it to the SparkFun board? Also, does this require calibration? Is it referred to as a wheel tick sensor? I plan to integrate it with sensor fusion to improve accuracy further.
The previous Google Earth .kml .jpg was created from a bare metal design I did for a client. A uBlox M8L (U17) was used on a light duty Chevrolet OBD2 SUV using the generic PID 0x0D (Veh Speed) @ 250ms OBD2 query and update rate to the M8L.
If my car has an OBD2, can I connect it to the Sparkfun F9R device to get speed sensor and direction data? How ? Is there a connection diagram ? Or is there another way to send speed sensor data from an ESP32 to the Sparkfun device?
I started such an investigation but didn’t went to the end. See my F9P/F9R logger.
I was able to get the speed of my car using the Adafruit CAN Bus FeatherWing - MCP2515. As far as I remember, I was able to get the speed expressed in cm per second (integer), several times per second, using a proprietary message. I was not able to get the speed from public message, which, with speed in km/h (integer) provide once a second, may not be enough precise to help the IMU.
I didn’t go any further despite some guys provided me tips on ublox forum. It is also not an easy hardware setup. The F9R was near driver, in the middle axis of the car while the ODB2 plug is on the left so the ODB cable has to go “through” the driver. Even more, the F9R is supposed to be above the center of the rear axle so, now, it is in the back of the car, more than 2 meters from the ODB plug. Cable is too short.
I would say that using a BT device on the ODB plug would be a much better option to avoid hardware issue but I don’t have any idea on how to implement that.
