SUCCESS!!!
Built CubeBlack and CubeOrange!!
Had to install:
p.s. Installed MAVProxy too.
Just one problem left, but maybe is due to Apple silicon, during sitl compile:
ld: warning: pointer not aligned at address 0x100227A9B
I get hundreds of misaligned pointers.
Looks like we are at same point now. Misaligned pointer.
Thanks for all your Help.
The problem is in this line of code:
logger.Init(log_structure, ARRAY_SIZE(log_structure));
in each of the Log.cpp for each SITL model.
So a simple dirty workaround would be to modify the beginning of the file as follows
//#if LOGGING_ENABLED == ENABLED
#if 0
so that every routine is compiled as {}.
Of course, the best is to accomodate log_structure to M1 arquitecture.
We would only miss the logging capability in sitl you think?
Possibly. At the beginning:
// Code to Write and Read packets from AP_Logger log memory
// Code to interact with the user to dump or erase logs
I’ll try shortly a simulation and see what happens, but the best is having log_structure adapted for M1 arquitecture.
At ardupilot/libraries/AP_Logger/LogStructure.h:
#define LOG_PACKET_HEADER_LEN 3 // bytes required for LOG_PACKET_HEADER
// once the logging code is all converted we will remove these from
// this header
So once the logging code is all converted…
I changed ardupilot/libraries/AP_Logger/LogStructure.h deleting PACKED:
// structure used to define logging format
struct LogStructure {
It links with original Log.cpp. Replay: I’ll try shortly.
Please let me know how it goes.
Thanks
With above workaround, SITL compilation and linking on M1 is successful. Here it is (8K):
SITL running on M1.
3D view captured from .bin log in M1.
QGC (female voice) on M1.
MP (male voice) on Windows PC (TCP).
All normal.
As seen, QGC has a very poor speech capability.
That is great, what did you do exactly to LogStructure.h ??
thanks,
Corrado
Only for SITL compilation:
ardupilot/libraries/AP_Logger/LogStructure.h
…
#include <AP_AIS/LogStructure.h>
// structure used to define logging format
struct LogStructure {
uint8_t msg_type;
…
Only delete PACKED.
Ok, thanks!!!
Corrado
The whole struct to be deleted?
Looking at LogStructure.h and don’t understand what to edit. Can you please make it a bit clearer?
*** UPDATE *** Erased all occurencies of PACKED in LogStructure.h and now sitl compiles.
Thank you very much.
@Webillo now if i start python3 sim_vehicle.py -v ArduCopter i get the following error:
ImportError: dlopen(/opt/homebrew/lib/python3.9/site-packages/gnureadline.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace ‘_add_history’
and it exits mavproxy. Is there a way to have sitl running as a separate object from mavproxy?
*** UPDATE *** started with option --no-mavproxy and it kind of started but than console is in following condition:
RiTW: Window access not found, logging to /tmp/ArduCopter.log
SIM_VEHICLE: Waiting for SITL to exit
I don’t think it is waiting for a connection…
For me it compiles and links deleting PACKED in that single line.
See this.
In my case I changed in mavproxy.py gnureadline to readline (I think you can remove gnureadline module completely if you have it). If you cannot find it, try to upgrade mavproxy.py, or use the one in GitHub.
If not, another stupid thing never tested in M1.
Ok, thank you for the explanations.
Corrado
Is there a #define we could use so that this one thing could be compiled out only when building SITL on Mac?
I found that this breaks --speedup i.e. if I use this hack to get SITL to built then if I pass the --speedup option the SITL process will crash with an illegal hardware instruction error. If I don’t set speedup it works fine.
It’s nice to having it working but it seems a bit dodgy to me.
Could the --speedup issue be related to SITL: crash on Apple M1 when the simulator is compiled for arm64 and --speedup is not specified at startup · Issue #19588 · ArduPilot/ardupilot · GitHub and AP_Logger_File: fix a SITL crash on arm64 when no speedup was specified on the command line by ntamas · Pull Request #19717 · ArduPilot/ardupilot · GitHub ?
It could be @ntamas . I have to look at this more because “something changed” recently and I’m not having this problem now. I think I still use the hack (remove PACKED) - the code compiles and builds and I have managed to run the entire suite of test.Plane scripts which include lots of various speedup values, so it must be working.
Another workaround that does not seem to require the removal of PACKED is to compile the simulator for x86_64 and run it through Rosetta, i.e.:
CFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" \
./waf configure --board sitl --debug && ./waf copter