From what I understand the reason for putting IMUs in the GNSS units is for when they are mounted far apart on very big aircraft, the remote IMU’s can feed back to the central flight controller, which will be better able to calculate pitch and roll angles.
1 Like
I stand corrected. I did try to find the full specs before posting, but they lump the docs together with the Here3, and the user manual does not list the IMUs.
I had a bit of a refresher on GNSS recently when looking for a replacement unit for my current one which is a UBLOX M8N based cheap clone. As far as I understand it the GNSS units used to directly report the calculated GNSS position complete with the all the drifts and gitters that comes with. Along with using RTK correction there is also a techinque where a GNSS system continually monitors IMU reports to see if reported GNSS movements are possible. Not sure if this is in play on the Here 3+ system.
Another interesting technique with these centimetre precision systems was using a pair of them to calculate gnss yaw.
Technology at this price point has cone a long way since the 3DR UBLOX M8N versions of my clone unit came out!
This topic has piqued my curiosity quite a bit, and I’ve read through your discussion with Michael over at CubePilot.
So far, I have added CubePilot’s hwdef files to my own fork, and after a few minutes of fiddling to remove the AP_Periph specific lines, I got waf to spit out a binary for Copter. I have no idea if it is actually usable, but it wasn’t hard to get that far!
My commit, showing changes to the CubePilot hwdefs: AP_HAL_ChibiOS: Draft update of Here3+ hwdefs for full AP build
I expect that a Matek node can supply most of the bare essential IO, as mentioned earlier here, but there are a few obvious challenges (and likely a few I’m missing):
- There’s no ADC exposed, so battery monitoring will have to be via some peripheral means.
- I’m not sure if an SPI SD card module can be used via a node’s SPI bus for logging (or scripting).
- The bootloader build is failing with the commit as is.
2 Likes
That’s awesome. I’m very keen to learn the code base better but it has been a while since I have been coding and I am in the middle of mov8ng my home office/workshop out of home into an office!
I thin a smaller project form me may be how to get SD Card access over CANBus. SD Cards have an indefinate life, so having a pair of data units recording and responding to data requests may well help. As far as I am aware there is no sd card inside the Here 3+ so mission/log storage would be reliant on onboard flash.
Regards SPI sd access there is an SPI port on the Matek L431 DroneCAN node, but it is setup for something like a barometer. So I would be looking to mod the AP_Periph software for the L431 node todo SPI sd card access over canbus.
That’s exactly what I meant by the second bullet point (logging via a node’s SPI bus). The bus is exposed and can be used for any number of supported peripherals. I’m not sure if an SD card module is one of those, and I suspect not. Writing a driver to support that is probably beyond the level of time/patience I have to devote. As such, unless the implementation is quite simple (or already exists), logging may remain disabled until someone else takes it on. I have a pending question on Discord on the topic.
2MB of flash is useless for typical AP logging and should probably not be attempted.
Playing catch up on terminology and naming here! Faff leading up to the move, the move, my kids birthday and my Mum visiting this weekend has left me fried!
Sounds like seeing how the SD Card works would be a nice ‘need’ or purpose to learn the code base. I’ll start having a look week after next.
I have a well tuned quadrotor that I can use for proof of concept, with or without logging. I have most of the required peripheral hardware on hand to give it a go once I’m confident that the build is sufficient.
I was hopeful that running AP on the Here3+ would provide a super tidy autopilot solution, but it seems there may be a bit of a spiderweb of external peripherals required to make it truly useful, so it’s almost an exercise in curiosity rather than utility unless I find a way to wrangle the required CAN node into a neat/tidy peripheral solution. My mental image at the moment really doesn’t make it seem more advantageous than the usual 30x30 flight stack, and it seems about break even for cost.
U can use ardupilot on here 3+ but not right now in future because ithave a on bord h757 and a imu on board it can but right now it’s not possible because ardupilot not ant firmware for that purpose it happens in future
Any updates? I’m wondering if I can buy a Here3+ or Here4 and use it to run the actual autopilot (copter) firmware.
Thanks…