As I stated in my first message, I have already run the calibration with the VG-AHRS app.
Also, I'm not using the python driver. I'm accessing the raw serial interface.
Now, having looked at the EKF code, the IMU's current firmware does not support having X/Y axes not on the horizontal plane (no correction is done on the Z axis), which won't work for me since it is mounted sideways (that is, with Y up and Z sideways).
To be clearer: I send through serial 'm', 'a', 0x1 (packet prelude and checksum omitted)
Then, repeatedly I send 'm', 'a', 0x0 which replies with a status of 0x1 (which I expect). It never goes to zero.
Ah. I assumed the calibration was happening on the IMU. I'm not using the Aceinna python driver, the IMU is embedded in a low-power board inside the system, and using the python stuff is just too cumbersome.
I was basically sending the MA commands through my C++ driver. Is there any way to perform the calibration "offline" ? I.e. logging the data and then doing the calibration ?
I've tried to run the magnetic alignment process. With autoend, it never finishes. Without autoend, the stop command does not make it stop.
I flashed the VG-AHRS app v1.1.3
One peculiarity is that the IMU is mounted sideways. Could that be the problem ? Is it an issue in general with the OpenIMU ?
I have created EP. The NAK was caused by a bug I introduced somewhere in the packet-to-type conversion logic. As was, it seems, the issue with flashing the firmware.
Thanks for the confirmation.
For those that would be interested, I've written down a protocol documentation - it has some stuff that's specific to our firmware, but most of it isn't: https://github.com/tidewise/drivers-imu_aceinna_openimu/blob/master/Protocol.md
OK ... so it seems that it was my fault. Sorry for the noise guys.
So, for the record, it seems that this packet is sent by the unit in case an invalid message is sent to it.
Can someone from AceINNA confirm this ?
Hi guys. Thanks for the info
To clear any confusion: the unit boots fine. The problem I have is that it becomes non-responsive after a JA command, which means that I can't upload a new firmware through the UART (works fine with JTAG)
I'm trying to update a few configuration messages (in sequence) with uP. It works ... mostly. After a few uP, I get a message that looks like
0x55 0x55 0x00 0x00 0x02 0x45 0x50 0x37 0x62
The message is valid (good format, good length, CRC passes). I don't know if it makes any sense, but the payload (0x45 0x50) is EP, which is the name of the configured periodic packet.
I'm assuming it is sent from the messaging layer ... would you guys have some insights for me ?
I had some trouble flashing a new firmware, so I decided to try to upload the firmware using the JTAG adapter and PlatformIO's Upload task in VSCode
It seems that now I can't upload a new firmware anymore. Would the upload have overwritten the bootloader ? If it did, how can I re-establish it ? If not, how can I find what is happening ?
Thanks in advance
Hi again ...
I wanted to implement having more than one periodic packet. However, I can't find the obvious place I'd need to have a look into, that is HandleUserOutputPacket.
Where is it called from ?
Thanks. That did the trick. I would suggest moving the GPS to UART_CHANNEL_1, which would make it easier to wire with the user UART, keeping the two pins of CHANNEL_2 for debugging.
I found out that the GPS channel is actually "Serial 2", not "Serial 1" as it seems the documentation hints. Is that expected ?
I tried to find out how to change that in the firmware, but I couldn't find how. Could someone help there ?
Thanks
Sylvain
@Sylvain-Joyeux said in How to propose changes to the core libraries ?:
We also have generic changes to the INS app. Would you be interested in those ?
Specifically, the changes listed in https://github.com/tidewise/firmwares-imu_aceinna_openimu/pull/1
We also have generic changes to the INS app. Would you be interested in those ?
Well. I've done the changes. What I am asking is whether you have considered including external contributions, and if yes how. I've originally created an issue on GitHub but since there's still no answer I'm guessing noone is listening there (unlike here, thanks !).
Since I want to get covariance values, I was thinking I could add the relevant code to the core libraries and propose them for inclusion on GitHub. What would be the process to propose these changes ? Could someone point to me to documentation on how to use a custom version of a dependency (so that I use my fork of the core libraries instead of the AceINNA distributed ones) ?