On the Solo, the companion computer is being seen by ArduCopter as a GCS. So you actually can’t even use the GCS failsafe on those. This can be corrected by changing some mavlink type IDs on the companion computer, but I do not know where or how that’s done on it.
@ Matt, randy
I thought Orange is the new Black 
with just a faster uC in. I didn;t pay close attention to sensors. My bad. Anyway, it used to sport a Here during 3.7-dev and 4.0.0-rc1/2 double-taped ontop of the Cube and calibrated instantly. Troubles started when I switched to a Here2, in I2C mode, both taped to Cube and on a foldable stand. The quad is very simple, four aluminum arms bolted to a pair of fiberglass squares and a makeshift landing gear. No payload. Just a cheap, somewhat expendable test bird.
GCS failsafe-wise, I’d have it disabled by default. From my experience, a FCC Taranis with a 5dB antenna still gets passthrough telemetry at 2.6 Km. With a R9 module, the figure gets extended past 5. A typical SiK radio is only good for 2 Km, and if there’s a tree or building blocking direct los on a portion of the flight, the link drops.
I’ve remembered a 4th possibility that can stop an autopilot from booting which is if there is not enough power provided especially if using a USB cable. We can confirm this is the cause by disconnecting all accessories (RC receiver, telemetry radio, anything else) and then try powering it up again.
@Mallikarjun_SE, @wicked1, @mtbsteve,
Thanks for the feedback re the GCS failsafe. I’ve created a PR to disable the GCS by default and expect to include this in Copter-4.0.0-rc5 (the next release candidate). Before merging I want to discuss with some other devs as well.
2 Likes
still not working
This discussion is getting long enough that I have created a new topic here.
Thanks for the report and your persistence!
1 Like
Did you try a different PC to connect?
I saw these flags being set in ArduCopter 4.0.3 as well when flying an original Pixhawk-based quadcopter as well. Any ideas why?
I saw these flags being set in ArduCopter 4.0.3 as well when flying an original Pixhawk-based quadcopter as well. Any ideas why?
These flags aren’t actually related to sensors.
These indicate whether the current flight mode is attempting to control xy
position (true for loiter, false for stabilize, for example).
Similarly for Z.
Peter
Visit Topic or reply to this email to respond.
In Reply To[6000_2.png]
rrr6399
December 18 When I test using the simulator, I’m seeing MAV_SYS_STATUS_SENSOR_XY_POSITION_CONTROL and MAV_SYS_STATUS_SENSOR_Z_ALTITUDE_CONTROL flags set
in the msg_sys_status.onboard_control_sensors_health. Is that just a bug in the simulator? Maybe a flow sensor and lidar is enabled by default, but not
imple…
Visit Topic or reply to this email to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, click here.
Peter Barker | Programmer,Sysadmin,Geek.
pbarker@barker.dropbear.id.au | You need a bigger hammer.
:: in what circumstances would you want reverse thrust for takeoff? --tridge
1 Like
Mystery solved! Thanks Peter!
I don’t know where to write exactly, I have a holybro gps module and I redid it for pixhawk. accidentally burned a compass. put a new compass and it is not detected by the system. I soldered 8853 and it worked. I soldered another new ist8310 and it does not work, what is the problem? ardupilot 4.0.3