BNO055 failure

hippy

Technical Support
Staff member
Yes you can reset 'hserptr' to zero, or you can simply use 'ptr=ptr+N' to take you to the Nth byte location of a subsequent packet.

The best way to tell if you can use HSERIN rather than background receive is to try it or look at a scope to see how quickly data is returned in response to a command.
 

lbenson

Senior Member
Yes, you can reset hserptr. I don't think you can be as fast with hserin as with background receive into scratchpad--you'd probably have to test to see if it works in your circumstances.
 

macrobeak

New Member
Edmunds,
I am very impressed you are trying to interface to the BNO055 with a PICAXE.
I have interfaced the BNO055 using another micro, and I can tell you it is a great chip!
It has all the IMU sensors and pre-processing on-chip, and it outputs high level 3D motion parameters, including roll, pitch and yaw, rotational velocities and even quaternions!
When I have more time I would like to make a quadcopter flight controller out of the BNO055 - I am sure someone has probably done it already.
Keep going and good luck!
 

edmunds

Senior Member
Edmunds,
I am very impressed you are trying to interface to the BNO055 with a PICAXE.
I have interfaced the BNO055 using another micro, and I can tell you it is a great chip!
It has all the IMU sensors and pre-processing on-chip, and it outputs high level 3D motion parameters, including roll, pitch and yaw, rotational velocities and even quaternions!
When I have more time I would like to make a quadcopter flight controller out of the BNO055 - I am sure someone has probably done it already.
Keep going and good luck!
Thank you! Did you manage to fire it up using UART or I2C? In case of UART, I would be very interested in your code, whatever programming language/compiler it was written for.

So far, I have not managed to get any sort of flight-usable speed out of this thing, but heading (yaw) numbers I am getting even from not very much calibrated device look plausible compared to the gibberish I was getting from a raw magnetometer. For the sake of comparison.

Edmunds
 

edmunds

Senior Member
The best way to tell if you can use HSERIN rather than background receive is to try it or look at a scope to see how quickly data is returned in response to a command.
It turns out HSERIN was actually not a very good idea on X2 in the sense it won't put anything directly in a variable anyway. So background receive it is, will try to get my counting right :).

Edmunds
 
Last edited:

edmunds

Senior Member
While I'm still feeling like walking a thin ice here, it seems I can get about 650us turnaround time for request data->get data in scratchpad->read it into a heading variable->reset pointers->go back to what it was I was doing. Adding some additional stability checks might extend it a little bit, but definitely fast enough to be worth continuing.

Feels good, need to take a break, :)

Edmunds
 

techElder

Well-known member
Edmunds, I've been watching your progress with great interest, too. That 650uSec loop sounds very interesting to me. Hope you find the time to post some of that code. I've been wrestling with the scratchpad loop myself.
 

edmunds

Senior Member
Dear all,

Here is an update before I call it a night. My overall impression is, while the communication link to the device is nowhere near as robust as I would like it to be, this should be possible to work with. I still don't think I can spare the normal hserxx(x) pins in the vehicle, so I will either learn to do this with the second USART module or use an I2C UART bridge.

My data acquisition loop that would basically be the entire interrupt on odometer step is about 1.7ms, which is very good. The problem is, quite frequently, I get crap back from the device, so I have to go and try to read something again. I wanted to time this, but this turned out impossible or at least not easy as timer1 is busy with hsersetup thingy and timer3 is just not fast enough to pick anything useful up. So I ended up counting loops instead. Not very scientific, but does the job :).

Most of the times the second loop works, but sometimes it takes as many as 10 attempts to make the device respond with something reasonable. With crap I mean good header and no data. Error I would understand, but proper error codes are very rare. The rate of crap reduces if I continue to increase the pauseus 800 to larger values, but the improvement stops at around 2.000/8us where I still get crap for every 10th read or so. So the 100us seems like a good delay for now. I guess I will have to just give up after 2 attempts and come back next time when running the vehicle.

Code:
main:
  do
    inc counter                                           'loop counter, just for testing
high B.4                                                'just to see something on the scope
    hserptr = 0 : ptr = 0                                 'reset pointers
    hserout 0,($AA,$01,$1E,$02)      'ask for yaw angle data [Start byte,Read,RegAddr,Length)
    pauseus 800                                           'anything below 100us (800@64MHz) makes the device very unhappy
;    SerTxd( "Starting...", CR,LF )
;    Do While ptr <> hSerPtr
;      SerTxd( "Got ", #@ptrInc, CR, LF )
;    Loop
;    SerTxd( "---", CR, LF )
;    ptr = 0
    if hserinflag <> 0 and hserptr = 4 then               'only want new and complete data
      if @ptr = $BB then                                  'valid response header
        get 2, H_L_byte, H_H_byte                         'load low and high bytes in the correct order into H_Word
        hserinflag = 0                                    'reset hserinflag for next loop
low B.4
        sertxd("Loop#: ",#counter," | Heading: ",#H_Word,CR,LF)
        counter = 0                                       'reset loop counter, just for testing
      else
        sertxd("Heading error",CR,LF)
        if @ptr = $EE then gosub UART_Error
      endif
    endif
    pause 1000
  loop
}

UART_Error:
  get 1, data_byte
  Select case data_byte
  case $01
    sertxd("WRITE SUCCESS",CR,LF)
  case $03
    sertxd("WRITE FAIL",CR,LF)
  case $04
    sertxd("REGMAP INVALID ADDRESS",CR,LF)
  case $05
    sertxd("REGMAP WRITE DISABLED",CR,LF)
  case $06
    sertxd("WRONG START BYTE",CR,LF)
  case $07
    sertxd("BUS OVER RUN ERROR",CR,LF)
  case $08
    sertxd("MAX LENGTH ERROR",CR,LF)
  case $09
    sertxd("MIN LENGTH ERROR",CR,LF)
  case $0A
    sertxd("RECEIVE CHARACTER TIMOUT",CR,LF)
  endselect
return
The entire file is attached below, not pasting the entire thing as it contains all the symbol definitions for registers and more code for initialization. I now need to read more about the actual sensor and its setup. It is entirely possible, there is room for improvement by setting it up better, not just using the default values for everything.


Cheers,

Edmunds
 

Attachments

macrobeak

New Member
Edmunds,
Further to your question above;
The Parallax Propeller was used to interface to the BNO055 breakout board.
The interfacing is done through I2C.
This forum thread gives some details and code;
http://forums.parallax.com/discussion/163121/adafruit-9-dof-breakout-for-quads
I used this code as a starting point, and I found the IMU data was very stable and the datasheet very informative and easy to use.
I built a learning rig of a simple 3 axis gimbal driven by continuous servos and was able to implement a demo IMU control scheme using PID and Fuzzy Logic without too much trouble.
 

edmunds

Senior Member
Edmunds,
Further to your question above;
The Parallax Propeller was used to interface to the BNO055 breakout board.
The interfacing is done through I2C.
This forum thread gives some details and code;
http://forums.parallax.com/discussion/163121/adafruit-9-dof-breakout-for-quads
I used this code as a starting point, and I found the IMU data was very stable and the datasheet very informative and easy to use.
I built a learning rig of a simple 3 axis gimbal driven by continuous servos and was able to implement a demo IMU control scheme using PID and Fuzzy Logic without too much trouble.
Thanks, great.

Edmunds
 

edmunds

Senior Member
Just a quick update.

This thread could soon be renamed something else, not BNO055 failure as I definitely have the device working by now :). I even can lap my small layout and get a memory-full of headings. The reason I know this, however is not that good. I have been battling calibration to exhaustion, so had to do something else for a while and that else turned out to happen in the same file. Switched off the calibration thing and took it for a spin. The data shows a couple of nice corners, but then, as expected with not calibrated device, it jumps away on a straight to some strange value and then shows a corner from there again. Not of much use except to prove the resolution is plenty and measurement noise is unlikely a problem.

The battle with calibration is that you basically need an entire application for that alone and being lazy by nature, I tried to shortcut it. On top of that, there are tricks and tweaks with every command with respect to timings and modes it requires to be set beforehand. Adafruit library has been a great help since I downloaded Arduino IDE and opened the source code. So I now have much better speed than in the beginning. I guess I will attack it tomorrow once again from ground up with a separate program, try to get that to work flawlessly and then try to integrate it back into the main thing.

Cheers,

Edmunds
 

macrobeak

New Member
Edmunds,
You are correct, calibration is quite a task.
However, if you are patient, follow the recommendations of the datasheet, establish a calibration loop and keep displaying the calibration register you can follow your progress to the magic 11111111 result!
 
Top