AP_Scripting: Add thrust stand #16813
Conversation
|
|
||
| -- Motor function to override | ||
| _motor_channel = SRV_Channels:find_channel(33) | ||
| local MOTOR_TIMEOUT = 3000 --(s) |
There was a problem hiding this comment.
| local MOTOR_TIMEOUT = 3000 --(s) | |
| local MOTOR_TIMEOUT = 3000 --(ms) |
| local now = millis() | ||
| _ave_callback = _ave_callback + 1 | ||
|
|
||
| if ((now - _ave_last_samp_ms) > _samp_dt_ms or _ave_last_samp_ms == 0) and available(i2c_dev) then |
There was a problem hiding this comment.
| if ((now - _ave_last_samp_ms) > _samp_dt_ms or _ave_last_samp_ms == 0) and available(i2c_dev) then | |
| if (now - _ave_last_samp_ms) > _samp_dt_ms) and available(i2c_dev) then |
| return protected_update, 100 | ||
| else | ||
| gcs:send_text(6, "Param set fail in init") | ||
| return |
There was a problem hiding this comment.
| return | |
| error("Param set fail in init") |
| function update() | ||
|
|
||
| -- Bodgy conversion from userdata to number | ||
| local now = tonumber(tostring(millis())) |
There was a problem hiding this comment.
| local now = tonumber(tostring(millis())) | |
| local now =millis():tofloat() |
There was a problem hiding this comment.
Really should be using the uint32 everywhere, and only convert in certain steps such as multiplying the delta time since last time to float. Anything else is as noted extremely bodgy, you will have actual errors in 4 hours of uptime (not an unreasonable amount of time for a thrust stand to be running)
| if all_set then | ||
| -- Now main loop can be started | ||
| return protected_update, 100 | ||
| else | ||
| gcs:send_text(6, "Param set fail in init") | ||
| return | ||
| end |
There was a problem hiding this comment.
| if all_set then | |
| -- Now main loop can be started | |
| return protected_update, 100 | |
| else | |
| gcs:send_text(6, "Param set fail in init") | |
| return | |
| end | |
| assert(all_set, "Param set fail in init") | |
| return protected_update, 100 |
Shorter and clearer then peter's suggestion. In practice though it's probably easier to just assert all your param set/saves above anyways where you do them, or just assert(foo.set_and_save() and bar.set_and_save() and ... )
| _led_chan = SRV_Channels:find_channel(98) | ||
| if not _led_chan then | ||
| gcs:send_text(6, "LEDs: channel not set") | ||
| return |
There was a problem hiding this comment.
If no LED's then we are done setting up, and doing things like setting up motor 1 below don't need to happen? That seems wrong.
|
Wow, fantastic! |
|
@Gone4Dirt can you address the comments so that this can be merged? |
|
@Gone4Dirt I may just be blind. Do you have either blueprints or cad files for your thrust stand or a site where you list them to buy and download. I like your design. If tytorobotics IE rcbenchmark had any of their 1585 thrust stand logic boards in stock I build a replica of their stands. Whatever reason the board is like $150 but they want 1100 with stand and load cells. Massive markup. |
This is a fun lua script that I have been working on for the past few months. I wanted to add another tool to the AP arsenal in terms of component selection / vehicle design. So I have designed a static thrust stand that uses scripting to take advantage of AP, its libraries, and mavlink for using the GCS for control and live telemetry. All of the CAD for the hardware will be open source and the little python post-processing tool I am making (still needs a lot of work though! :-D )
About the Project
Here is the thrust stand I have made:
Here are some of the features of the script:
There will be a blog post going up on the forum soon where I will get more of the details out.
The other thing that I am quite please about it there is a lot of flexibility in this. Not everyone will necessarily need/want torque data for example, so they can easily get one of the low cost thrust stands off of bang good and plumb the load cell from that into this system to get way more data and automation.
I think one of the biggest benefits to users will be the ability to more easily get thrust data for expo fitting on multi-copters and VTOL planes. The post-processing tool I am working on will help with this.
The data captured by this script is dumped to a *.CSV file so the bar to entry for processing the data is very accessible. For example, it is easy to use the output in the already existing google sheets expo fitting tool.
Here is an example of some of the data I am getting out:
Throttle Ramp Tests:
Throttle Transients:
Here is what the post-processor currently looks like. As I say, needs a lot more work.
About the code
The top section of the code is a port of the C library from sparkfun into LUA, to be able to make use of the NAU7802 amplifiers on the I2C bus. This script therefore uses @IamPete1's I2C scripting PR (#14276).
The lower section of the script is then the actual thrust stand code.
This script does depend on a few other PRs for scripting bindings:
#15857
#16741
#16742
Although the later two PR's are on hold to better PRs that would enable this functionality. So I will update the thrust stand to incorporate those PRs as and when they are merged.
Finally, this PR is marked as WIP at the moment as I am still chasing out one bug, which I don't believe is actually a fault of this lua script. Basically, I am using a Matek F765. The amplifiers have the same address and are therefore on two seperate I2C busses. For some reason the amplifier for the thrust load cell 'looses' data and LUA gets nil values in return. I do have the OLED screen on the same bus, however I have removed this and the problem still occurs. I have also ruled out EMI as both thrust and torque I2C buses are run next to each-other and the fault always occurs on thrust and not torque. Plus both lines are run through a grounded metal braid. Also, I have swapped the thrust and torque amplifiers to rule out a faulty amplifier. This is an intermittent problem so doesn't always cause issues. Turning down the sampling rate reduces the likely hood of the issue happening, but I am pretty sure thats just because it is reducing the traffic on the bus. I think it might be a race condition or DMA buffer issue, but I am getting well out of my area. So, if anyone has any ideas/pointers on how to debug this I would love to hear them.