Jump to content

sciss

Members
  • Gesamte Inhalte

    10
  • Benutzer seit

  • Letzter Besuch

sciss's Achievements

Newbie

Newbie (1/14)

0

Reputation in der Community

  1. Thank you for the update. The reported rate is now accurate (I tested with period 10 and it indeed gives 100 Hz). This patch however has a new problem - you can't save the calibration, at least from brickv, it seems to crash the brick, the connection is lost when you press 'save calibration'; you can bring it up again by disconnecting and reconnecting USB, but then you have to calibrate again. Best, ..h.h..
  2. Ok, so the trick in that video is that it uses three IMUs, and assumes the first (top-most) is not moving but only rotating; so it has precise rotation for that, then extends a vector of known length from there, adds a second rotation, extends another known vector, adds the third rotation; thus only rotations are used, and this doesn't solve any real motion tracking problems. Has anyone found good filtering techniques to minimise the drift problem of the accelerometer?
  3. Found it: https://www.tinkerforge.com/de/doc/Software/Bricks/IMUV2_Brick_TCPIP.html#imu-v2-brick-tcpip-api
  4. This is from the doc of `setSensorConfiguration`: * The default values are: * * * Magnetometer Rate 20Hz * * Gyroscope Range 2000°/s * * Gyroscope Bandwidth 32Hz * * Accelerometer Range +/-4G * * Accelerometer Bandwidth 62.5Hz However, when I call `getSensorConfiguration`, it yields [magnetometerRate = 5, gyroscopeRange = 0, gyroscopeBandwidth = 7, accelerometerRange = 1, accelerometerBandwidth = 3] So, I wonder how that reflects the default values? Does `accelerometerBandwidth` of 3 correspond with 62.5Hz? Where can I read up on this?
  5. Note that `brick-flash` worked, so it's not urgent, but perhaps it worth checking that the UI flashing actually works on Linux.
  6. So running as normal user, the 'save' action for flashing doesn't work because of missing permissions. The docs suggest that I run `brickv` as root, but that doesn't work either, because the GUI doesn't come up: $ sudo brickv X Error: BadAccess (attempt to access private resource denied) 10 Extension: 130 (MIT-SHM) Minor opcode: 1 (X_ShmAttach) Resource id: 0x159 X Error: BadShmSeg (invalid shared segment parameter) 128 Extension: 130 (MIT-SHM) Minor opcode: 5 (X_ShmCreatePixmap) Resource id: 0x2400010 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2400011 X Error: BadDrawable (invalid Pixmap or Window parameter) 9 Major opcode: 62 (X_CopyArea) Resource id: 0x2400011 I also tried `sudo adduser myself dialout`, followed by regular `brickv` start, no success. So it seems like a catch-22 here.
  7. Here are my measurements: val m = Seq( 1 -> 559.5, 2 -> 286.2, 3 -> 187.0, 4 -> 141.7, 5 -> 114.6, 6 -> 95.8, 7 -> 82.0 ) val e = m.map { case (p, hz) => hz / (1000.0/p) } e.mean // 0.5688 e.sorted.apply(e.size/2) // 0.5724 Left is periods specified in milliseconds, right is actually frequency measured. That is to say, the frequency seems to be by factor 0.5724 lower than it should be according to specification. Also this way it seems impossible to produce the correct rate to read exactly all 100 samples per second that the BNO055 should output.
  8. I'm wondering how you can get a non-drifting signal like here: In the comments, the OP claims that only the quaternions are needed. They are indeed quite stable on my display, while the linear acceleration is very noise (in the magnitude of 0.1 m/s^2 error). How would I do the integration based on quaternions? It sounds odd to me, as they are only giving orientation, right? Any ideas? best, ..h.h..
  9. Directly connected. No. Perhaps the problem is in brickd or the way the listener is implemented in Java?
  10. Hi there, I'm new to this; just received an IMU v2, and all seems pretty cool, great documentation and software examples! I'm using the Java bindings, and I notice two problems with the call-back approach (trying linear accel at the moment): Neither does the call-back receive any time stamp information, nor does the nominal rate given through `setLinearAccelerationPeriod` have any reasonable correlation with the actual rate. Also, there is no information available about the acceptable sampling rates. Comparable IMUs usually have a resolution of 200 to 500 Hz. I can't seem to get close to that. For instance, if I set `imu.setLinearAccelerationPeriod(10)`, the observed sampling rate is around 57.2 Hz, where it should ideally be 100 Hz. This adds to the problem of the missing time stamps, because I notice that for small periods / high sampling rates, the same values might be polled numerous times, and I want to experiment with position tracking, so the duplicate values would increase the already existing noise. So I would be grateful, if somebody could share some light on how to get tight and precise timing when polling for example the linear acceleration. Thanks!
×
×
  • Neu erstellen...