@Marc Dornan
coming back to your airspeed & servo suggestion:

I don't know nothing about planes, and don't know what servos you are talking about, and how they're handled in ArduPilot.

However, ArduPilot already supports uavcan.equipment.actuator UAVCAN messages, which sends out Servo info. So, what you may want to do is to explore/figure out if these messages do carry the servo info of the servos you are taking about. If so, doing a servo node would be quite simple, and I would be VERY willing to do such a firmware.

An airspeed sensor would need a bit more work, but is should be very similar to baro, or the power brick, or the STorM32. So, this too should not be very difficult to do, and I also would be very willing to try this.

The only byline would be that I have committed myself already to two other projects (ICM20602 and DJI CAN bus support), so I would not come to that in the next few weeks.

But I'm seriously interested to do the above .

Originally Posted by OlliW

@Marc Dornan
coming back to your airspeed & servo suggestion:

I don't know nothing about planes, and don't know what servos you are talking about, and how they're handled in ArduPilot.

However, ArduPilot already supports uavcan.equipment.actuator UAVCAN messages, which sends out Servo info. So, what you may want to do is to explore/figure out if these messages do carry the servo info of the servos you are taking about. If so, doing a servo node would be quite simple, and I would be VERY willing to do such a firmware.

An airspeed sensor would need a bit more work, but is should be very similar to baro, or the power brick, or the STorM32. So, this too should not be very difficult to do, and I also would be very willing to try this.

The only byline would be that I have committed myself already to two other projects (ICM20602 and DJI CAN bus support), so I would not come to that in the next few weeks.

But I'm seriously interested to do the above .

I think my Dev board is arriving today so I can start on the GPS mag. It should be easy enough this get that going on the bench. I am building a cheap Bixler 3 as a plane to fly Master Ardupilot and it will go on that.

As for servos, actual CAN equipped ones will almost certainly cost a fortune each but they are available, and I have vowed not to go down that route of professional grade gear. What would be nice is if a small board could demonstrate servo CAN control and some limited feedback. Positional feedback is probably going to be hard to achieve in a servo not designed to do this but the most important information is current usage. So my very hazy thought would be to have a little board that could adapt existing servos to CAN protocol and measure their current usage. If I can find an existing 9g CAN servo that is not extortionately expensive I can try one one the bench.

Please do not worry about timeline at all. No deadlines or pressure. My Bixler 3 is being designed to have swappable electronics. I want it to fly iNav, Ardupilot, and Paparazzi by just putting a new 3D printed electronics bay in. I can fiddle with this meanwhile. I have spent some time making the servos removable by having printed holders, in case I ever need to do this.

If you need an airspeed sensor for bench testing at some point (only if you want one) I can send you a spare one.

PS: What are you doing with DJI CAN? I used that library to get FRSky telemetry from a Naza canbus a few years back.

Originally Posted by OlliW

as regards enabling the power brick:

First, knowing me now this may not come unexpected: I would strongly advice to first fly with only the gps-mag node in the system, and only once this is sorted to add further nodes, such as the power brick, and especially the UAVCAN escs. You are using the v3-Solo compile, which is TOTALLY untested, one maybe shouldn't stretch luck too much

Then, I don't have the precise settings in mind (I'm on a trip right now), so I will tell you later. This is what I recall:

* There are two UAVCAN messages which can be used, the CircuitStatus message, which is member of the standard messages, and the GenericBatteryInfo message, which is my home-brewed message. In both cases you currently need BetaCopter to use either.

* The power brick can be configured to emit either of them (or both LOL), the node has respective parameters. I have configured your power brick to emit the GenericBatteryInfo, and not the CircuitStatus message.

* You may notice that these messages have an "id" field, for CircuitStatus it is called circuit_id, and for GenericBatteryInfo I have forgotten, maybe battery_id. You need to know this value for your power brick. So, pl, inspect the power brick's parameters and read off this value (it's maybe 1, I have forgotten however)

* ArduPilot: The above messages are digested by AP_BattMonitor, and and it has its parameters in the BM section, if I'm not mistaken.

* In the BM section you should find a parameter BM_SERIAL_NUM with which you can set the "id" to which the battery monitor should listen.

* there is an additional parameter in the BM section which needs to be set to activate using the UAVCAN, BM_MONITOR: Set it to 8 for using the CircuitStatus message, and to 10 for using the GenericBatteryInfo message

* to be sure set BM_VOLT_PIN = -1, and BM_ CURR_PIN = -1

Perfect, exactly what I needed to know. Mine is definitely setup with the GenericBatteryInfo message. I'll check the ID.

"did you got this working now using the MP GPS pass through? " No I got one of my FTDI adapters to work, but only after I did and nothing changed in my setup that I finally figured out how to save the baudrate changes to the GPS. So I think it would have worked with passthrough if I had saved correctly.

Like most quads I am tight for space. So I will probably not listen to your advice and jump in with both feet. (that is my way, another genetic defect) It is a test platform for this project and everything is easy to fix if it were to crash. I also am waiting for more JST-GH cables so someone may beat me to the prize darn it.

So next I will get the powerbrick installed and the wires to the ESC's. I will run two batteries, one for the main power to the ESC's and one for the flight electronics. The original Solo had noise problems on the power bus and I want to try and eliminate that.

Onward into the breech!

@Marc Dornan:
I think we agree on this "have a little board that could adapt existing servos to CAN protocol". That's what I too would have thought. At first I would however only output a PWM signal (or up to 4). Adding current feedback would be a second step. Position feedback wouldn't make that much sense to me (it's a servo).
Since ArduPilot does already have support for sending UAVCAN servo messages, my question was if the servos which you need are among those. This would make it quite easy to achieve a UAVCAN servo. Thus, maybe you could check if your servos are among those which are handled by UAVCAN already.

I want to add DJI CAN bus support to the STorM32 gimbal controller.

@mike_kelly:
I knew that you wouldn't listen to my advice . But that's of course perfectly fine. I just don't want to feel responsible for any mishap LOL.

the batch is waiting

Originally Posted by OlliW

@Marc Dornan:
Thus, maybe you could check if your servos are among those which are handled by UAVCAN already.

I do not own a CAN servo. I just posted a link to one. I am open to maybe getting one, at some point. But I would rather not. I like the idea of being a little cheap about this. I will do some digging though and find out what the level of support is. I am open to getting one to play with if it is not crazy expensive. Apparently they do feed back all sorts of data. I guess for safety-critical applications knowing if a servo is not moving when the controller telling it to move may be useful. But that is obviously way OTT for our purposes. I would think just controlling a conventional servos and peripherals with one bus would in itself a huge advancement -- current monitoring would be way down the line.

Storm32 on DJI CAN- now that sound great.

misunderstanding: I wasn't trying to say that you should get a CAN servo to test if the ArduPilot UAVCAN messages handle the servos you need (wouldn't work anyhow since this CAN servo likely wpouldn't speak UAVCAN ...)
I was trying to suggest that you somehow figure that out through your understanding of ArduPilot and by which "channels" your servos are handled

Originally Posted by OlliW

misunderstanding: I wasn't trying to say that you should get a CAN servo to test if the ArduPilot UAVCAN messages handle the servos you need (wouldn't work anyhow since this CAN servo likely wpouldn't speak UAVCAN ...)
I was trying to suggest that you somehow figure that out through your understanding of ArduPilot and by which "channels" your servos are handled

Got it. Will do.

Originally Posted by OlliW

I knew that you wouldn't listen to my advice . But that's of course perfectly fine. I just don't want to feel responsible for any mishap LOL.

the batch is waiting

It is not that I don't listen and appreciate your cautious approach. But in this project it is not easy to replace the ESC's first with PWM. The space inside the frame must be drilled to fit the ESC's and I don't want to drill mounting holes for two different ESC's nor to buy extras given the excessive cost of the UAVCAN ESC's. Second I need a power module and again the mechanics of how I mount them inside the frame kinda demands a plan and to adhere to that plan.
The GPSMag would be easier to test with an I2C unit first because it is externally mounted.

Plus I have a testing frame that straps the multirotor down on a perch that is telescoping and allows the craft to "fly" restrainted. Not so much risk for testing. Plus being impatient and having to wait so long for parts I just don't have the energy to build it and tear it apart multiple times.

Lastly I might not win the badge if I wait!!

no explanations needed, Mike


btw, you may have seen I've edited the above ArduPilot parameters post, but you certainly had this pieced together already

Great progress today. I got everything working on the Solo itself. It "sees" the powerbrick in Mission Planner, not just in UAVCAN gui. The GPS and Mag work and the ESC's are recongnized.

Now I just have to wait for some connectors.

Yippie!

@OlliW What is the relationship in UAVCAN between canbus 1 and canbus 2? Can both be used ? What if you have both turned on does the firmware look on both busses? Does everything have to be on the same bus? Can you just set the Arducopter parameter to select which is the primary and which is the secondary?

Thanks

this sounds like fantastic progress

as regards the two can buses, I'm not totally sure
I think the code is such that one can use each can bus independently (e.g. run UAVCAN on one and whatever on the other), but also as dual-backup like it is intended by UAVCAN ... at least that's the intention, as much as I understand

I would think that it should be possible to configure both as UAVCAN, and to connect e.g. the ESCs to one and the gpsmag and power brick to the other ...

BUT: I'm not sure that anyone has tested this, and in view of the experience with other one-would-think-it-should-work features of the current UAVCAN implementation I think you should be most happy if you manage to get one configuration to work ... one should not underestimate the significance of this comment !!!

(you don't have a dual gps setup, as it seems ... be glad ...)

if you intend to do such fancy stuff you would be probably better off asking at ardupilot

Originally Posted by OlliW

this sounds like fantastic progress

as regards the two can buses, I'm not totally sure
I think the code is such that one can use each can bus independently (e.g. run UAVCAN on one and whatever on the other), but also as dual-backup like it is intended by UAVCAN ... at least that's the intention, as much as I understand

I would think that it should be possible to configure both as UAVCAN, and to connect e.g. the ESCs to one and the gpsmag and power brick to the other ...

BUT: I'm not sure that anyone has tested this, and in view of the experience with other one-would-think-it-should-work features of the current UAVCAN implementation I think you should be most happy if you manage to get one configuration to work ... one should not underestimate the significance of this comment !!!

(you don't have a dual gps setup, as it seems ... be glad ...)

if you intend to do such fancy stuff you would be probably better off asking at ardupilot

Well this would be a good time to find out. I have to wait for the finish cables so I might as well experiment with the two bus and see. I'll also try the second bus as the UAVCAN backup configuration once I get enough cables. We are here to discover!

I spent hours today with "one-would-think-it-should-work" all the while trying to fry my Solo until I remembered that the blasted cables have the red wire going to GROUND!

the uc4h nodes do not support UAVCAN redundant configuration ... so connect them just and only to one bus

Have my STM board and will get this tested this week. Could not get to it over the weekend.

Originally Posted by OlliW

the uc4h nodes do not support UAVCAN redundant configuration ... so connect them just and only to one bus

Of course, but we don't know yet if they will work dispersed between the two buses. If the buses will work in a fully redundant configuration, which you are right is most likely the reason for two buses, then if a device disappears from one bus it must be seen on the other bus. Or the redundancy does not work.