Aparetly the TI board i have uses same registry addresses as Maxell so they should be compatible. With 3.4 if i hook it up and fiddle with registries the flight controller freezes.
I was looking at the rc code and noticed that only current and voltage are defined for use so i guess the current aim is to make those Maxell batteries usable rather than making batteries smart? If i uncomment the registry values for other parameters then in user defined code i should be able to request state-of-health, cycle-count etc data?
@George_Muirhead On the SBS wiki article it says that its sort of a de facto standard. What the differet boards do internaly probably differs but the interface available to SMBus seems to be the same.
Nice work Karl.
Yes, the current Maxell battery driver is just a starting point with basic functionality (voltage and current) but the maxell battery itself also doesn’t provide as much info as say the Solo battery. Hopefully we can do more (with the maxell or these TI batteries) including what you’ve mentioned and also individual cell voltages, setting battery capacity, % of battery remaining.
Are the TI batteries readily available or is it still very DIY?
Its DIY as its custom made batteries with TIs SBS controller. This chip to be exact. I can get quite a bit of data from my batteries but not everything that the chip offers is imlpemented yet. Will be quite a while before it can become a fully blown product if ever. If you need someone to test the interface then from this chips perspective im happy to help.
Generally, Autotune would never have been possible under such conditions without PosHold
Turning into the wind works perfect!
Due to the higher wind speed during this test turning into the wind can look like a “flyway”. I guess this is the phase when wind direction is measured.
Problem:
Autotune failed. At least there were no changes in the PIDs. There is no indication if it failed or finished successfully in the logs. Autotune logging simply stopped.
At that point the copter started drifing in the wind - it seemed like normal AltHold behaviour.
I landed and disarmend with autotune still on. But no changes in the PIDs.
Questions:
What went wrong?
I can imagine that AT failed due to too high wind speeds. But, how can this be seen/determined?
Another thing - maybe related to Copter 3.5:
Getting Params over USB after connecting in Mission Planner is sometimes unusually slow. I saw this behaviour on different boards (Pixracer, AUAV-X2) and different USB cables. Downloading a log afterwards was as fast/slow as usual. I’ll make some further tests.
Thorsten,
Thanks for the report. I think I know what this is. We throw away the first request-for-parameters if it arrives before all our internal objects have been created (it takes a few seconds after startup). I think you’ll find if it’s possible to wait a couple seconds after startup before connecting and downloading parameters it will be fast. Tridge has mentioned this issue to me and I think we have a fix in mind.
I wonder if something like that can feed 3DR Solo battery SMBUS data to the pixhawk too? It would pretty amazing to eventually see cell voltage and such in the Pixhawk telemetry and logs.
Pulling SMBUS data from the 3DR Solo smart batteries would be pretty epic too. Imagine being able to see the cell voltages on the Ground Station in flight? Alerts and failsafes based on cell voltage could help prolong the life of batteries that get unbalanced. Having it in the dataflash logs opens up a lot too.
We should have read the posts closer. Though we thought the manual tuning for our copters was spot on we were so-so wrong. We upgraded our shop Centurion MKIII to 3.5.0-rc2 and gave autotune a whirll.
Our flight engineer Berlin envoked in Loiter and was surprised it was holding position through the first few twitches but then I heard a mess of expletives from her as the copter yawed off 90 degrees. Told her to hang on to it then realized it was by design.
We ended up with a large change in PID’s, Though the numbers looked scary to us we are amazed that a good flying copter is now an amazing flying copter.
Kudos to all the development team for this release candidate.
@Pedals2Paddles
Matt, thanks for having a look!
I am using autotune since the beginning and it is the first time that the new PIDs have not been saved. This is why I posted it here. However, from the log it seems that it completed Pitch, Roll and Yaw tuning. So this is a little strange to me. I am also not 100% sure but I guess there was no autotune complete message.
I had some problems autotuning this configuration before. But the result was wrong PIDs which had been saved. So, I hope for less wind tomorrow…
Solo battery was the first SMBUS implementation ArduPilot had for quite a long time. We have now added Maxell too (thanks to Tatsuya Yamaguchi for the contribution). Since this is a standard protocol we hope to generalize the driver in the future, but unfortunately both of these brands don’t completely respect the standard.
Test flew 3.5.0.rc2 on Auav Pixracer on F450.
Stab, Alt Hold, Circle, Loiter, Poshold, Auto Mision with RTL and Disarm, and AutoTune in Loiter.
Al worked great !, No problems. Kudos" to all.
Best Version yet. LOVE the new Autotune. Even in a 5~10 mph breeze, once it drifted downwind 20 feet or so and yaw spun around to face wind direction, it just stayed over a a 5 foot spot. Amazing !
Thanks for all the work you all have put into this.
Joe
I made some further Autotune tests with different copters and 3.5 rc2. Today it worked perfectly on the small quad. But again I had one autotune on a bigger hexa where the new PIDs had not been saved. Apart from that tunes are perfect! The autotune waltz is nice to watch as well!