CANbus IMU
13 views
Skip to first unread message
Crashmatt
Dec 3, 2010, 2:03:41 AM12/3/10
to RC servo interface
Aim: Turn UDB into an IMU connected to CAN.
All Matrixpilot (non DCM) code and functions will be on the
CAN Interface
Anything related to measuring position in space is on the UDB
The first cut of the IMU code uses 700bytes RAM.
There is plenty of space there to do mailbox buffering of the IMU
data.
At first look the difficulties are:
Re-writing the state machine for startup
Communicating mixed status and control flags
The flags and dcm_flags registers are both read and write.
Synchronising the IMU measurements with the interface
All Matrixpilot (non DCM) code and functions will be on the
CAN Interface
Anything related to measuring position in space is on the UDB
The first cut of the IMU code uses 700bytes RAM.
There is plenty of space there to do mailbox buffering of the IMU
data.
At first look the difficulties are:
Re-writing the state machine for startup
Communicating mixed status and control flags
The flags and dcm_flags registers are both read and write.
Synchronising the IMU measurements with the interface
Crashmatt
Dec 4, 2010, 1:13:30 PM12/4/10
to RC servo interface
IT WORKS!
Just had the first HILSIM flight of separated UDB IMU and interface
autopilot.
There are some flags and signals to connect.
For example, The set gps origin does not work.
The startup sequence needs some fine tuning
Taking care of IMU and autopilot synchronisation.
This has been by far the easiest way to split the UDB-Interface
functions.
Celebratory bottle of Leffe is on its way. Bless those Belgian monks.
Matt
Just had the first HILSIM flight of separated UDB IMU and interface
autopilot.
There are some flags and signals to connect.
For example, The set gps origin does not work.
The startup sequence needs some fine tuning
Taking care of IMU and autopilot synchronisation.
This has been by far the easiest way to split the UDB-Interface
functions.
Celebratory bottle of Leffe is on its way. Bless those Belgian monks.
Matt
Peter Hollands
Dec 4, 2010, 6:01:06 PM12/4/10
to rc-servo-...@googlegroups.com
Matt, that absolutely brilliant. Many congratulations.
Pete
Pete
Crashmatt
Dec 5, 2010, 5:47:10 AM12/5/10
to RC servo interface
Pete,
UDB_EXTRA shows peak 13% interface processor loading.
The UDB/IMU processor loading is not relevant any more. We know it is
not overloaded.
Matt
On Dec 5, 12:01 am, Peter Hollands <peter.holla...@gmail.com> wrote:
> Matt, that absolutely brilliant. Many congratulations.
>
> Pete
>
UDB_EXTRA shows peak 13% interface processor loading.
The UDB/IMU processor loading is not relevant any more. We know it is
not overloaded.
Matt
On Dec 5, 12:01 am, Peter Hollands <peter.holla...@gmail.com> wrote:
> Matt, that absolutely brilliant. Many congratulations.
>
> Pete
>
Peter Hollands
Dec 5, 2010, 9:51:01 AM12/5/10
to rc-servo-...@googlegroups.com
And a large percentage of that loading is probably created by the printf style statements in sending SERIAL_UDB_EXTRA. Moving to a binary format could well save another 6 percent or so of CPU. (yes, as much as that). I hope to have the MAVLink cpu figures soon.
When you compile up the UDB IMU again sometime, could you switch on the MAX_STACK free RAM reporting routine in options.h and tell us what that is as well ? (a low priority question, just curious. no matter if you have other priorities.).
Best wishes, Pete
When you compile up the UDB IMU again sometime, could you switch on the MAX_STACK free RAM reporting routine in options.h and tell us what that is as well ? (a low priority question, just curious. no matter if you have other priorities.).
Best wishes, Pete
Crashmatt
Dec 6, 2010, 8:59:47 AM12/6/10
to RC servo interface
Pete,
I didnt know that MAX_STACK was there.
The IMU processor loading and stack are now hidden from telemetry.
The telemetry reports the interface processor/stack loading.
I should support transporting the loading over CAN to the telemetry.
As you say, low priority.
To be clear, 13% was the total interface procesor loading, not just
for UDB_EXTRA.
The magnetometer is now running on the interface. Should soon have its
data sent to the UDB/IMU.
This is nice because the interface I2C port does not conflict with a
programming connector.
Matt
On Dec 5, 3:51 pm, Peter Hollands <peter.holla...@gmail.com> wrote:
> And a large percentage of that loading is probably created by the printf
> style statements in sending SERIAL_UDB_EXTRA. Moving to a binary format
> could well save another 6 percent or so of CPU. (yes, as much as that). I
> hope to have the MAVLink cpu figures soon.
>
> When you compile up the UDB IMU again sometime, could you switch on the
> MAX_STACK free RAM reporting routine in options.h and tell us what that is
> as well ? (a low priority question, just curious. no matter if you have
> other priorities.).
>
> Best wishes, Pete
>
I didnt know that MAX_STACK was there.
The IMU processor loading and stack are now hidden from telemetry.
The telemetry reports the interface processor/stack loading.
I should support transporting the loading over CAN to the telemetry.
As you say, low priority.
To be clear, 13% was the total interface procesor loading, not just
for UDB_EXTRA.
The magnetometer is now running on the interface. Should soon have its
data sent to the UDB/IMU.
This is nice because the interface I2C port does not conflict with a
programming connector.
Matt
On Dec 5, 3:51 pm, Peter Hollands <peter.holla...@gmail.com> wrote:
> And a large percentage of that loading is probably created by the printf
> style statements in sending SERIAL_UDB_EXTRA. Moving to a binary format
> could well save another 6 percent or so of CPU. (yes, as much as that). I
> hope to have the MAVLink cpu figures soon.
>
> When you compile up the UDB IMU again sometime, could you switch on the
> MAX_STACK free RAM reporting routine in options.h and tell us what that is
> as well ? (a low priority question, just curious. no matter if you have
> other priorities.).
>
> Best wishes, Pete
>
Reply all
Reply to author
Forward
0 new messages