Yeah I thought that maybe the case, I was asking on here to see if it was being looked at, but I guess not.
I’ve asked the same question on their forum this evening too.
From a general stand point it would be interesting to know how much spare processing power there is. If you had everything on DroneCAN could a second autopilot behave like a GNSS unit until it detected an issue with the main controller and then take over to attemp safe land etc? Guess the probability of that being needed is very small.
Actually the Cube Red (next version to Orange) has a complete redundant autopilot setup within it for this reason. So I think once that comes out we will see more software support for a full backup autopilot suite.
Even just running a very compressed flavor of ArduCopter loaded on the Here 3 that allows RTL or Landing would be great. Even just a simple stabilization support with manual control would be adequate.
I also just noticed the Here 3+ shares the same exact processor as the Cube Orange+ (STM32H757) - so I wouldn’t be surprised if it had the power for the entire autopilot stack.
If I understand the STM specs right it has 2MB of flash, and 1MB of RAM, from the other poster image shared the same processor that is on Here4.
The processor on the 2.4.8 clone only has 256MB of RAM, with the same 2MB of flash. Seems like potential for rovers at least, maybe save your gear on a last chance on a airborne vehicle.
Mhm - regardless I think the ability to run ArduPilot on the Here 3+ would a great addition (even if its just for Rovers, Trackers, Boats, etc.). Integrating support for aerial vehicles (most likely with the addition of an external barometer) would just be another plus.
We already have a custom build suite that allows you to select a limited subset of features for loading onto older/weaker autopilot boards.
My main interest - aside from it potentially running my rover better than in collaboration with a 2.4.8 clone - would be having it on a boat to bring it back to port. Perhaps in the instance of a bit of a nasty dose of emf from lighting for example upsetting the main controller or simple component failure.
I will try to set up the Here3+ with very little hooked up to the 2.4.8 aside from the Here3+ and the DroneCan L431 node.
In the background I will hunt for a guide for setting up an ubuntu machine for compiling standard Ardupilot software sets, then custom, and finally trying to work out getting that on the Here3+.
All that said my C/C++ experience is limited so I strongly suspect someone else will achieve it before me!
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.
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!
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.
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
