View Single Post
  #30   Spotlight this post!  
Unread 10-01-2014, 02:00
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 356
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Open Source IMU designed for FIRST robotics

The nav6 continually streams the updates, so the CRio just listens and doesn't have to send any requests. The update packets are terminated with a line feed, and as I understand it the FPGA receives and buffers serial characters until the termination character is received, then the buffer is made available to the processor. So in principle this is pretty efficient. The remaining work is parsing the values into the yaw/pitch/roll/heading angles.

I don't have detailed performance metrics for this, but anecdotally we ran a prototype of this w/the same protocol in our C++ robot last year. The robot software was also servicing 4 bit-banged Avagotech absolute angle sensors to track our swerve drive steering angles, and read out angles from each of these at 50Hz. Our checks showed the total CPU load was roughly 50%. So my best guess, needs to be verified, is no more than 10% CPU on a VxWorks robot for receiving/decoding the updates.

All that said, do you think it's worth adding a configuration option to decimate the update rate?