Forum Replies Created
If heading isn’t being populated, then the system isn’t receiving the NMEA sentences it needs. That likely explains the lack of time synch as well.
The dynamic range of the accelerometers is a function of the sensor itself, not the calibration. What I described is correct regardless of the sensor’s dynamic range.
Sure. Suppose, for example, you measured the following:
X = 10
Y = -15
Z = 4230
You might not be able to get a measurement where X and Y are both exactly 0, something like the above would be close enough. In this case, you’d get
// This converts raw units to acceleration in m/s/s
float scale_factor = (float)1 / 4230 * 9.8;
accel_x = X * scale_factor;
accel_y = Y * scale_factor;
accel_z = Z * scale_factor;
This actually isn’t perfectly accurate, since there will also be biases on the acceleration measurements, and each axis will have different biases and scale factors. To distinguish between bias and scale factor, you’d want to orient the sensor so that the body frame z-axis points orthogonal to gravity (so, rotated exactly 90 degrees). The non-zero measurement on the z-axis is the bias. Let that bias be represented by the variable B_z. Then the scale factor can be computed with:
float scale_factor_z = (float)1 / (4230 – B_z) * 9.8;
accel_z = (Z – B_z)*scale_factor_z;
The scale factors and biases for the X and Y axes will be different from the Z axis, so you’d need to repeat the calibration for every axis. It’s actually easiest to get all this data of you mount the sensor on a perfect cube, sitting on perfectly level table. Then you can get measurements from each axis both aligned with and orthogonal to gravity, to extract biases and scale factors.
If you have a super-accurate gimbal, you can do something more sophisticated by collecting data from every axis along with truth from the gimbal. Then you can compute all the calibration, including cross-axis alignment, scale factors, and biases, in one batch process. That’s what we did with the GP9 while we were still selling it.
Note that the accelerometers on the UM7 are consumer-grade, and the biases and scale factors aren’t very repeatable. You can get kinda close, but you’ll always be a little off.
The conversion is easier if you use processed data instead. The raw data is completely uncalibrated. If you want to use the raw data, orient it so that X and Y are zero. The z-axis measurement is gravity, so you can get the scale factor out of that.
If power was applied to an expansion header pin while power wasn’t on, it might have damaged the device. It is a little odd that some commands work and others don’t. Is it possible that there is an intermittent connection from a damaged connector pin?
On the UM7, the GPS data is just passed-through. On the GP9, it is used to improve the attitude estimate.
The UM7 isn’t open-source, but the code is available for purchase. Unfortunately, it’s not inexpensive.
Polling data registers instead of having the UM7 broadcast them automatically won’t change anything. If anything, it will make the delay worse.
You can increase the broadcast rate until you get something closer to what you need, but in all cases you’ll need to utilize the reported system time in the packet to determine exactly how much time has elapsed between samples. You’d have to do that anyway to properly account for unpredictable serial port latency, which can be substantial (tens to hundreds of milliseconds, depending on what the system is doing) on a non-RTOS OS like Windows or even Linux.
No, the main loop runs continuously, and independently of the system time. The system time is maintained by a hardware counter that runs continuously. Each time through the main loop, the system checks the system time to determine what, if any, events should be executed – including transmission of packets.
MOST of the time, the core is busy estimating states in the extended kalman filter. So here is the order of events that would cause delay:
1) The system checks the current time. No packets need to be transmitted.
2) The system samples sensors
3) The system takes the new sensor data and computes updated states
4) Greater than 1 millisecond has passed since the last time we checked the time. We check again. It is now past time to transmit a COM packet.
5) The packet TX task is added to a queue, along with all other TX packets. The packet is transmitted as soon as the UART is available.
6) When the packet is transmitted, it takes the most recent data, which will have been sampled after the 20 millisecond target period.
The extra delay is a result of the way the UM7’s architecture is set up. Internally, the UM7 uses a cooperative multi-tasking architecture. On each iteration through its main loop, the UM7 samples sensors (if they are ready), computes state estimates if needed, and initiates transmission of packets that need to be sent. Packet transmission is not driven asynchronously – meaning, when it comes time to transmit the next packet, it has to finish whatever it is currently doing before it pushes the packet to the serial transmit buffer.
Another factor affecting delay is the number of packets being transmitted and the baud rate of the port. When packets need to be transmitted, they are added to a queue, and the packets are sent to the serial hardware one at a time by the DMA controller. The more packets that are being transmitted, and the lower the baud rate, the longer the delay.
So yes, you can expect the timestamps to be more than a couple microseconds away from nominal.
but the variation of [the delay] definitely has to be much less than 1 ms and the mean of such noise has to be zero.
The delay from your PC’s serial port hardware and OS will most certainly not be zero mean, nor will it less than one millisecond. Delays from the machine can be extremely lengthy and unpredictable.
The actual transmission rates can be expected to be less than the target due to limitations of the serial port’s bandwidth. To get data faster, you can
1) reduce the number of packets being broadcast by the UM7
2) increase the baud rate
3) connect to the UM7 with something running an RTOS to remove additional unpredictable latency.
But there is nothing wrong with the UM7, it is performing as expected.
You have to reconnect at the new baud rate to send the flash commit command. Then you can cycle the power and the settings will be maintained.
I wouldn’t think that the BeagleBone would have a hard time synthesizing a good clock rate, nor has the UM7 had those kinds of issues before. If there is a lot of bad data coming in, here is where I would look (in order of likelihood):
1. Make sure that the BeagleBone and the UM7 share a common ground.
2. Make sure that the logic level for the BeagleBone is compatible with the 3.3V logic level of the UM7
3. Check for an intermittent/bad connection on the TX and RX lines of the UART. An oscope can help you determine whether the signals are clean.
4. Check your parsing software. If it fails to retrieve bytes from the receive buffer fast enough, bytes could be dropped.
Interesting. No, it is definitely not normal for the majority of the packets to be invalid. Bad checksum errors should be very rare. What baud rate are you running? You might try lowering it to a different setting to see if that improves the bit error rate.
There is no scaling factor required. The system time is based on the rate of an internal crystal oscillator, so it should be pretty solid.
The fact that the two intervals you reported would be indicative of two different internal clock rates is suggestive that something is happening on the logging end. What are you using to collect and log the data? My suspicion is that data from the sensor may be being dropped as it comes in because it isn’t being collected fast enough. The most recent packets would be dropped and the logged timestamps would correspond to old packets.