christianrauch / ros-multiwii

ROS Node for MultiWii and Cleanflight flight controllers

ROS node for MultiWii / Cleanflight flight controllers

This ROS nodes uses the MultiWii Serial Protocol (MSP) to communicate with MultiWii and Cleanflight based flight controllers.

It reuses many of the mavros message definitions and topics and is therefore compatible to some visualisation and control nodes (e.g. joystick teleoperation) that are part of the mavros_extras package. The current implementation supports control over RC channels or direct motor access (active DYNBALANCE), arming/disarming by a service and it publishes IMU values and current RC/motor states.

ros-multiwii's Issues

catkin cannot find msp

I am getting issues compiling the ros-multiwii package as catkin cannot find msp. So where should i install your msp package so that catkin finds it?

copter_visualization with ros-multiwii

Would it be possible to provide a launch file/example on how to use multiwii data to visualise the drone with mavros_extras?

MWC Multiwii

Hello, I am trying to use this package with an MWC Multiwii FC. The gy86,launch gets refused by my FC, and the betaflight_rpi_zero.launch does not publish anything other than parameters. Is the MWC board not compatible with this package, or am I missing something here? It is not a problem at all if it is not compatible, I have spent hours looking through your code trying to understand why it is not publishing (I am a novice), and just want to make sure I am not barking up the wrong tree.

ID 101 and 114 not subscribing

Hello, I am the same person of MSP problem in the other repo. I've been out of the lab for a few days. Today I went back to the drone, and I'm having the following problem when running the ros package:

process[multiwii-2]: started with pid [1315]
message ID 101 not subscribed
message ID 114 not subscribed

After a while I get the following errors:

Version marker 62 is not recognised!
Message marker 204 is not recognised!
Version marker 255 is not recognised!
Message marker 0 is not recognised!
Version marker 58 is not recognised!
Message marker 6 is not recognised!
Version marker 108 is not recognised!
Message marker 255 is not recognised!
Version marker 243 is not recognised!
Message marker 0 is not recognised!
Version marker 0 is not recognised!
Message marker 106 is not recognised!
Version marker 0 is not recognised!
Message marker 77 is not recognised!
Version marker 62 is not recognised!
Message marker 77 is not recognised!
Version marker 33 is not recognised!
Message marker 246 is not recognised!
Version marker 255 is not recognised!
Message marker 255 is not recognised!
Version marker 249 is not recognised!
Message marker 0 is not recognised!
Version marker 1 is not recognised!
Message marker 0 is not recognised!
Version marker 101 is not recognised!
Message marker 255 is not recognised!
Version marker 249 is not recognised!
Message marker 255 is not recognised!
Version marker 247 is not recognised!
Message marker 136 is not recognised!
Version marker 0 is not recognised!
Message marker 198 is not recognised!
Version marker 36 is not recognised!
Message marker 255 is not recognised!
Version marker 3 is not recognised!
Message marker 0 is not recognised!
Version marker 0 is not recognised!
Message marker 0 is not recognised!
Version marker 104 is not recognised!

Arming service argument

Greetings,

first of all thank you for sharing your code :)

Went through it and was wondering what argument does the arming service take?

According to the code the res and req are both of type uint8_t so should the service be called with an int?

Port Utilisation

This issue impacts both this project as well as it's msp dependency.

Would be interested in a port utilisation metric that indicated the upload and download rate as a %, similar to how cleanflight displays it:

I am happy to implement it but wanted to discuss the design considerations before proceeding. I was planning to:

• Add 2 new variables in SerialPortImpl structure called bytesDownloaded and bytesUploaded
• Instrument MSP::receiveData() to add the number of bytes received to bytesDownloaded. This will be done by adding 3 bytes for MSP header, 2 bytes for data_size and MSP id, the data size (equals data length value) and 1 byte for CRC.
  Could also do this in MSP::read() if you recommend it
• Instrument MSP::sendData() to add the number of bytes sent to bytesUploaded. This value will be msg.size().
  Could also do this in MSP::write() if you recommend it
• Add a new functions to MSP.cpp called getTxBytes() and getRxBytes(). These return the byte values and reset the counter to 0.
• Add 2 new functions to FlightController.cpp called getTxBytes() and getRxBytes() which invoke the client.getTxBytes() and client.getRxBytes() calls and return the respective values.
• Implement ros::Rate class and poll the fcu every second, calculate the rates based on the data and transmit onto topic /port_utilisation

Looks like a simple and useful feature. Let me know if interested.