Forum Replies Created
-
AuthorPosts
-
Hey John,
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?
-
Hi Jeff,
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.
-
Hi Andrey,
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.
-
Hi Andrey,
You wrote:
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.
-
Hi Saddan,
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.
-
Hi Jason,
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.
-
The US Dept. of Commerce and Dept. of State both place limitations on types of products that can be exported without a license. Unfortunately, there isn’t a clear dividing line that indicates what can and cannot be shipped. The GP9’s integration of GPS with inertial sensors put it into a gray area, where one or both of the aforementioned bodies could possibly have a problem with it shipping without a license.
There is a possibility that the GP9 could ship without a license, but the process for applying for permission is lengthy and potentially expensive, and we sell the GP9 for too little to justify incurring that cost.
-
This reply was modified 6 months, 3 weeks ago by
Caleb.
-
This reply was modified 6 months, 3 weeks ago by
-
The UM7 only provides position and velocity data if an external GPS module is attached.
-
A basic overview of how we do calibration can be found here: http://www.chrobotics.com/library/sensors-for-estimation We don’t currently have an app note to describe methods of determining calibration coefficients.
-
No, calibration requires that rotation is performed about all three axes during calibration.
-
AuthorPosts
