What does this mean for people like @jstroup1986 and I already using H7 FCs in the form of the Pixhawk6C mini?
In terms of what? Here it was using the correct parameter value for the hardware. Use a better rangefinder, use the lua script…
Yes - these results and comments are encouraging.
If the sole reason to establish the origin is to determine the magnetic variance (declination) then there is a far simpler way I’d like to propose.
It is simple to find the magnetic variance for any location. This web site will automatically show the magnetic variance of the location of the IP address of the computer requesting the web site:
And as you can see from this map, the magnetic variance value can cover hundreds of miles.
My proposal is to create a single variable for magnetic variance. If the value of the parameter is is “-1” - then EKF3 uses it’s table look up as it does now. If there is an value in the parameter, EKF3 would use the parameter’s value instead.
This would allow copter to permit arming immediately without GPS.
An added bonus of this approach would be that in locations of strong localized magnetic disturbance, it could be accounted for using such a parameter.
This is just the beginning of our work for indoor copter operation. We’ll be working on it more as we decide how best to approach autonomous operation.
Thanks for your support!
Hi @jstroup1986,
AP has a built-in world magnetic model database which it uses to sanity check the values coming back from the compass. It is possible to turn off that check.
It’s also possible to manually override the declination using the COMPASS_DEC parameter.
TBH, I’m not quite sure why you’re opposed to providing the EKF origin as a lat,lon. We have a script that makes it easy and it doesn’t need to be exact. The issue with trying to NOT provide the EKF origin is we will hit various other limitations (like the GCSs inability to provide auto mode missions using relative coordinates) and it will blow up in terms of work and complexity. It may be possible to remove the setting of the EKF origin but I’m not sure any developer is going to pick up the development work required in the near term.
Hi @rmackay9 ,
The mission behind my inquiry is enabling STEM students to use ArduPilot multi-copters successfully in an indoor arena. My thoughts are that if procedures are more simple, the student projects will benefit.
Interesting about the COMPASS_DEC parameter.
It’s not clear that COMPASS_DEC is even used - as it’s default value is 0. If this parameter is in use, then ArduPilot is always navigating with reference to true north. No doubt there are a few layers of complexity going on here. For example how does magnetic north from a magnetometer compare with moving baseline?
If COMPASS_DEC is being used - shouldn’t it’s default be something like “-1” to tell the firmware to use the declination look up table?
And COMPASS_DEC uses units of radians. I’ve never seen declination or magnetic variance reported in radians.
I tried setting the COMPASS_DEC parameter to my local magnetic variance - it did not change the pre-arm requirement to set a home location.
There are many more hurdles to cross to provide STEM students with an ArduPilot platform for indoor flight. But if we can start by something as easy as setting a parameter so the operator doesn’t have to like to a ground control station to set EFK Home, that would be really helpful.
One additional comment. Most of the references I’ve come across for indoor flight use PX4. The ModalAI products are a case in point. Maybe I’m wrong about this.
Thanks!
To see how easy it is, I wonder if you could try loading the ahrs-set-origin.lua script onto an autopilot?
Re the compass declination, please have a peek at COMPASS_AUTODEC and you’ll probably see how it works. Yes, COMPASS_DEC is sadly in radians but the conversion from degrees to radians is just a multiply by about 57 and there’s no need to set these parameters in any case.
Moving baseline is also known as “GPS-for-yaw” and there’s very little relationship between compass declination and GPS-for-yaw.
ModalAI is an AP Partner and participated in the recent AP developer conference. AP supports both the VOXL1 and more recently the VOXL2. I have a starling 2 max that flies beautifully using AP and I’ll publish a video of this in the coming weeks.
Hope that helps
I think we’re thinking about this issue differently. I’m thinking of it as an educator. Perhaps you are as well. But to choose to use a LUA script instead of adding a small piece of functionality seems more like the perspective on an engineer.
I have no doubt that adding lua script you suggest is easy. But it’s particularly easy for anyone who knows what scripting and lua scripts are, how they are loaded on flight controller, and how their function is initiated.
Take for example the lua script that’s used for the CubePilot neopixel LED’s. To stay active it employs a recursive call to itself on the return - something well beyond the “hello world” scripts many novice programmers have experienced.
I appreciate that if lua scripts can help reduce the expansion of the ArduPilot codebase, it’s a benefit to developers.
Because of the open source nature of ArduPilot, I haven’t come across discussions about the end users as “customers.” But in my opinion they are customers - and the products they buy to use ArduPilot feeds to donations from manufacturers that helps the DEVs keep the lights on.
The customers of the copter my team is striving to sell to the STEM market is competing against equipment such as those by ModalAI - running PX4.
I’d really like to maintain and grow the ArduPilot user base by making it as simple as possible for novice students to use ArduPilot in their projects.
Thanks!
We definitely care about the complexity of the system and trying to make it easy for our users to use AP. This comes up often on the weekly dev calls, feel free to listen in or share your opinions… the call is every Tuesday morning at 8am Japan time.
We definitely recognise that requiring a lua script for a feature adds a barrier (which we would like to avoid) but at the same time we have real limits on the maximum firmware size we can put on most autopilots. So our solution is the custom build server and lua scripts.
We don’t have to agree though of course, “PR’s welcome” as we say!
Thank you. I’ll consider a PR, but it would be nice to have your support.