- Joined
- Jan 20, 2019
- Messages
- 183
- Reaction score
- 141
- Age
- 40
telemetryData.crc8 = st24_common_crc8((uint8_t*)&telemetryPayload, sizeof(telemetryPayload));
Indeed - it seems I already forgot what I wrote there myself
St16 v1.
- Thread starter Crashnburn
- Start date
Indeed - it seems I already forgot what I wrote there myself
The code I linked to earlier uses the checksum.h file from the mavlink git hub and that seems to successfully calculate the CRC for the drone to gimbal messages. At least for the gimbal movement messages that i was sending.Probably yes. When I did this, the RS was detached. Exactly the RS is present in the 2.4 ZigBee downstream, but a secondary link is possible too. Do the rest till 04, after that I'll take a look for 5 and 6 again.
Did you do the CRC? If you have any questions, drop them in the private thread, where you was invited. I probably restore in my mind almost all. When I did this, the interest in future development was only mine.
Now, I see, Helmut is up too.
Dylan
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
Byte 39 (after the error flags) is GPS_accH. The value is factor 20 compared to that what is shown in flight logs (telemetry).
bit5 and 6 in nsat should be GPS fix type but will not provided by Typhoon H. I saw it always as 0. Bit 7 (the highest) is "GPS used" as you have it already implemented. Error flags 1, 2 and 32 are common used, the other seems to depend on vehicle type. I saw a message about 8000ft limitation the Typhoon not has.
IMU status (byte 34), pressure_Compass_staus (byte 35) still needs some further investigations. My thoughts are in q500log2kml manual (chapter 3.3).
Need to check the reactions of the ST16 on the different values deeper soon. With the SR24 on Raspberry PI I have now a good tool to feed the St16 with all, also useless, informations an look whats going on. Flight logs will be created as soon as telemetry messages arrive.
----------------
@Pöllö: I use the latest FW for a long time without problems. But I have destroyed something due to bad battery. It is difficult to observe a fast drone during "sport flying" and look at the same time on the tiny voltage display.
That#s why I would like to have the Voltage Warnings on the ST16. ST16 ignores the voltage value and reacts only on the error flags.
This means:
BAT_LOW_THR --> Voltage warning 1; bit 0 in byte 38 of the telemetry message is 1
BAT_CRIT_THR --> Voltage warning 2; bit 1 in byte 38 =1
It would be very nice to send those error flags via telemetry. ST16 will be warn by vibration alarm.
br HE
- Joined
- Jan 20, 2019
- Messages
- 183
- Reaction score
- 141
- Age
- 40
Hi h-elsner!
How are you doing? Nice to hear that the firmware has been working OK for you, I am going to push the sources to GIT this weekend for this version, and then start implementing new features for it. I'll add at least those voltage error flags there to prevent bad things happening again with bad batteries, before going deeper into implementing the camera serial protocol and perhaps that one little "special request" of Vaklin. And I am definitely going to take a look also at the flashing adapter discussed on the PX4 thread.
Sad to hear you had a nasty crash due to a bad battery. Can you repair it?
My backlog regarding things to be done with the Typhoon and TBird is pretty long, and modeling 3D printable spare parts (or even more..
) for the drone has been one of those items for a long time on that to-do list... I had actually plans during spring to design a complete 3D-printable Thunderbird that could run on Yuneec's or 3rd party boards (FC, ESCs etc.), but I have yet to do it. Things are going forward on that field too however, since during spring I got my first "commercial" 3D-printer from my friend (a heavy-duty old Minifactory one with lead screws and steel chassis) and I've been learning how to design lightweight parts for efficient additive manufacturing. Plenty of new things and ways to think about design to learn, as I am coming from CNC milling and machine shop background when it comes to 3D modeling and machine design. Br,
TR
Last edited:
Is there an unused ADC input for a current probe? Alarm from the angle of I/U slope will be more efficient than just low voltage alarm.
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
This depends what PX4 autopilot is doing/can do. For the ST16 no changes are planned and this thing will only rreact on Error flags.
You can do high sophisticated computing in Autopilot FW. Thunderbird is open source, you are invited ;-).
br HE
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
The software for Raspberry Pi to control a car or boat by ST10 or ST16 is ready and it works. I'm still working on some mechanical things to lift the camera out of the car for FPV. It was grown up from the SR24 test tool (which is still working and useful for me to understand the UART connection of the SR24).
As building block there are 4 units:
SR24_dec: Provides data and methods to handle UART SR24 and decode the messages.
SR24_chsets: This reads the configuration which controls the assignment between channels and HW ports. It is the mediator between decoded messages and GPIO ports.
SR24_ctrl: This unit handles the GPIO ports of the Raspberry Pi (by sysfs).
SR24_log: Provides basic logging function (just for curiosity, not really needed). But all of you know, I like log files.
The project is still here:
github.com
br HE
As building block there are 4 units:
SR24_dec: Provides data and methods to handle UART SR24 and decode the messages.
SR24_chsets: This reads the configuration which controls the assignment between channels and HW ports. It is the mediator between decoded messages and GPIO ports.
SR24_ctrl: This unit handles the GPIO ports of the Raspberry Pi (by sysfs).
SR24_log: Provides basic logging function (just for curiosity, not really needed). But all of you know, I like log files.
The project is still here:
GitHub - h-elsner/SR24_decode: Read and decode data from Yuneec ZigBee receiver SR24. Test tool for Raspberry Pi.
Read and decode data from Yuneec ZigBee receiver SR24. Test tool for Raspberry Pi. - h-elsner/SR24_decode
github.com
br HE
The software for Raspberry Pi to control a car or boat by ST10 or ST16 is ready and it works. I'm still working on some mechanical things to lift the camera out of the car for FPV. It was grown up from the SR24 test tool (which is still working and useful for me to understand the UART connection of the SR24).
As building block there are 4 units:
SR24_dec: Provides data and methods to handle UART SR24 and decode the messages.
SR24_chsets: This reads the configuration which controls the assignment between channels and HW ports. It is the mediator between decoded messages and GPIO ports.
SR24_ctrl: This unit handles the GPIO ports of the Raspberry Pi (by sysfs).
SR24_log: Provides basic logging function (just for curiosity, not really needed). But all of you know, I like log files.
The project is still here:
GitHub - h-elsner/SR24_decode: Read and decode data from Yuneec ZigBee receiver SR24. Test tool for Raspberry Pi.
Read and decode data from Yuneec ZigBee receiver SR24. Test tool for Raspberry Pi. - h-elsner/SR24_decode
br HE
This looks pretty cool!
Have you ever tried using a Raspberry Pi to emulate a CGO camera? I tested naming an 5G wifi access point something like "CGO3_1234567" and the ST16 will bind with it and think it is a camera, but then error out during the initialization of it. I'm thinking that if we configure the Raspberry Pi up as an appropriately named 5G access point and to stream the RTSP video feed to the correct url then it might work even with the error for not being able to initialize it. Or, since we know the expected responses we could setup a server on the raspberry pi to respond to the initialization request also.
I was working on this but I'm having finding a 5G wifi adapter that will work on my raspberry pi and I struggle to get stuff to work in Linux anyway.
Dylan
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
The CGO3(+) communicates with ST16 by CGI commands. I think (not tested) it is no problem to simulate this. Example:
Initialization:
ST16 sends:
"http://192.168.42.1/cgi-bin/cgi?CMD=INDEX_PAGE"
CGO3+ answers (JSON):
{
"rval":0,
"msg_id":"257",
"param":"1",
"fw_ver":"3.2.34(E)",
"cam_mode":"2",
"status":"vf",
"iq_type":"1",
"white_balance":"0",
"sdfree":"31119360",
"sdtotal":"31154176",
"exposure_value":"0.0",
"video_mode":"3840x2160F30",
"speed_rate":"54M auto",
"record_time":"0",
"awb_lock":"0",
"ae_enable":"1",
"audio_sw":"1",
"shutter_time":"15",
"iso_value":"ISO_3200",
"photo_format":"dng+jpg" ,
"audio_enable":"1",
"rtsp_res":"720P",
"photo_mode":"1",
"photo_num":"1",
"photo_times":"1",
"ev_step":"0.000000",
"interval_ms":"333",
"soft_ver":"30234",
"cam_scene":"0",
"left_time":"0",
"metering_mode":"2",
"x_ratio":"0.00",
"y_ratio":"0.00",
"layers":"1",
"pitch":"0",
"yaw":"60",
"timer_photo_sta":"0"
}
I have a test tool implemented in Q500log2kml on the bottom of CGO3 page. You can enter any command you like an copy the answer for documentation.
A list of commands attached. Wich one are working depends on camera but most of them are the same. The are rare commands that are not integrated to the ST10/16 GUI but working.
Intresting examples:
GET_SHARPNESS and SET_SHARPNESS
GET_WIFI_SPEED and SET_WIFI_SPEED
br HE
Initialization:
ST16 sends:
"http://192.168.42.1/cgi-bin/cgi?CMD=INDEX_PAGE"
CGO3+ answers (JSON):
{
"rval":0,
"msg_id":"257",
"param":"1",
"fw_ver":"3.2.34(E)",
"cam_mode":"2",
"status":"vf",
"iq_type":"1",
"white_balance":"0",
"sdfree":"31119360",
"sdtotal":"31154176",
"exposure_value":"0.0",
"video_mode":"3840x2160F30",
"speed_rate":"54M auto",
"record_time":"0",
"awb_lock":"0",
"ae_enable":"1",
"audio_sw":"1",
"shutter_time":"15",
"iso_value":"ISO_3200",
"photo_format":"dng+jpg" ,
"audio_enable":"1",
"rtsp_res":"720P",
"photo_mode":"1",
"photo_num":"1",
"photo_times":"1",
"ev_step":"0.000000",
"interval_ms":"333",
"soft_ver":"30234",
"cam_scene":"0",
"left_time":"0",
"metering_mode":"2",
"x_ratio":"0.00",
"y_ratio":"0.00",
"layers":"1",
"pitch":"0",
"yaw":"60",
"timer_photo_sta":"0"
}
I have a test tool implemented in Q500log2kml on the bottom of CGO3 page. You can enter any command you like an copy the answer for documentation.
A list of commands attached. Wich one are working depends on camera but most of them are the same. The are rare commands that are not integrated to the ST10/16 GUI but working.
Intresting examples:
GET_SHARPNESS and SET_SHARPNESS
GET_WIFI_SPEED and SET_WIFI_SPEED
br HE
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
Finally my demo project is working fine. SW is updated at github.
- forward/backward on throttle,
- steering on roll
- turn signals on yaw (yaw configured as 3-way-switch)
- hazard light on tilt mode
- front light on gear switch
- headlight flasher on aux button
- camera lift on tilt slider (again as 3-way-switch).
br HE
- forward/backward on throttle,
- steering on roll
- turn signals on yaw (yaw configured as 3-way-switch)
- hazard light on tilt mode
- front light on gear switch
- headlight flasher on aux button
- camera lift on tilt slider (again as 3-way-switch).
br HE
Last edited:
I was able to configure a raspberry pi zero with a dual band wifi usb dongle as an access point and to stream its camera to "rtsp://192.168.42.1:554/live". That stream is viewable on my PC and when I try to go to connect to it on the ST16 it seems to connect and I can select the CGO3 camera but then fails to initialize (as expected) and doesn't display video. I also tried on the ST10 with the same results.
I also tried configuring the stream a rtsp://192.168.110.1:554/cam1/h264 and selecting the "GOPRO" camera option on the ST10. I thought that might work because it looks like @Vaklin has that working in another thread, but it didn't for me. It seemed like most of the time (though possibly not everytime) when the ST10 was trying to initialize the GOPRO camera then my raspberry pi would lock up (kernal panic'd, etc). So it is possible that I if I just block the html initialization requests with the firewall maybe the GOPRO (MK58) emulation will work on the ST10 initialization times out?
I might try that, but what I think I'm going to focus on is installing node.js on the raspberry pi and trying to use it to reply to the CGO3 initialization request with the json response you posted. I don't know anything about node.js, but this link seems to make it sound like it would be fairly easy to set up that sort of reply.
Raspberry PI server - GPIO ports status JSON response
I'm struggling for a couple of days. Question is simple, is there a way that can I create a server on Raspberry PI that will return current status of GPIO ports in JSON format? Example: Http://19...
stackoverflow.com
Dylan
Some recommendations:
- the pixel format should be YUV422p or YUV420p. Both works, the second is a very little bit faster but very colourless for IR palettes. Be sure your source is in one of these formats or use FFmpeg to transform it to a proper one.;
- transport protocol should be H.264;
- to use port 554 usually is necessary to open it with sudo, because it is below 1024;
- The WiFi interface itself should have any IP (better is x.x.x.0) and final destination IP should be 192.168.42.1. The interface should be transparent.
- in my configuration VLC on Pi shows nothing but the FFplay works very well;
- ST10 with GOPRO selected send nothing more than request to RTSP on port 554. Some ICMP on every second, which is not answered from Pi (IDK why), but this doesn't mess the flow at al.;
- add some loopback v4l2 (kernel module, should be compiled for the best results) and use FFmpeg to manipulate the stream;
- block unwanted WiFi on the Pi to be sure you're working in an clear environment;
- the screen size for the picture on the ST10+ is 330x192 or something around.
- the pixel format should be YUV422p or YUV420p. Both works, the second is a very little bit faster but very colourless for IR palettes. Be sure your source is in one of these formats or use FFmpeg to transform it to a proper one.;
- transport protocol should be H.264;
- to use port 554 usually is necessary to open it with sudo, because it is below 1024;
- The WiFi interface itself should have any IP (better is x.x.x.0) and final destination IP should be 192.168.42.1. The interface should be transparent.
- in my configuration VLC on Pi shows nothing but the FFplay works very well;
- ST10 with GOPRO selected send nothing more than request to RTSP on port 554. Some ICMP on every second, which is not answered from Pi (IDK why), but this doesn't mess the flow at al.;
- add some loopback v4l2 (kernel module, should be compiled for the best results) and use FFmpeg to manipulate the stream;
- block unwanted WiFi on the Pi to be sure you're working in an clear environment;
- the screen size for the picture on the ST10+ is 330x192 or something around.
Last edited:
BTW, with ST10+ and emulated GOPRO is enough to do rescue missions with an IR camera in hot white or hot black. There are not necessary additional commands to change palette and so on. For more sophisticated things, as a palette change, switch between IR and LowLight cameras and so on is very reasonable to rewrite some part of the Flightmode.apk in the ST16 to prepare a brand new camera communications protocol. This will give a chance to send redundant commands to the copter and so on. Here I'm away before to have some program's skeleton.
On another topic, a guy said this is not so dificult. For me is for now...
On another topic, a guy said this is not so dificult. For me is for now...
Node.js did seem to make it easy to setup a webserver to respond to the CGO3 initialization requests from the ST16. Initially I set it up to only respond to the "http://192.168.42.1/cgi-bin/cgi?CMD=INDEX_PAGE" command with the JSON response that @h-elsner posted above. That didn't work (ST16 still says failed to initialize), but then I noticed that that is for the CGO3+.
So went here:
bitbucket.org
and setup my Node.js webserver to respond to the INIT_CAMERA command with the JSON response listed there. That also didn't work so I started trying to look at what the last command the ST16 was sending. I saw that it sent a GET_STATUS, so I added the response for that command. Still fails to initialize.
After that I saw it was sending a "CMD=SET_RTSP_VID&Reslution=720P" command. The problem is that I don't know the correct JSON response to that command.
Does anyone know what the correct response is to that command and/or if there is a standard 'OK' response? I don't have a CGO3 to experiment on and for some reason the ST16 reports "wrong camera type selected" right away if I try to emulate the CGO3+.
Dylan
So went here:
denis_loh / CGOCameraLibrary / wiki / Home — Bitbucket
bitbucket.org
After that I saw it was sending a "CMD=SET_RTSP_VID&Reslution=720P" command. The problem is that I don't know the correct JSON response to that command.
Does anyone know what the correct response is to that command and/or if there is a standard 'OK' response? I don't have a CGO3 to experiment on and for some reason the ST16 reports "wrong camera type selected" right away if I try to emulate the CGO3+.
Dylan
h-elsner
Premium Pilot
- Joined
- Mar 23, 2016
- Messages
- 1,945
- Reaction score
- 1,639
- Location
- Bavaria / Germany
- Website
- h-elsner.mooo.com
To catch answers of any CGI commands from camera you can use q500log2kml. I can make a Raspberry Pi 32bit version if you need that.
There is a tabsheet "CGO3" with a test tool on the bottom of the page.
Enter only the body of the command (i.e. SET_RTSP_VID&Reslution=720P'). Prefix 'http://192.168.42.1/cgi-bin/cgi?CMD=' will be automatically added. Below is the field for the return value. "rval":0 means, command checked and executed successful. By double click on this output field, the return value will be copied to the clipboard. The cam must be already connected to 5GHz WiFi and the INDEX_PAGE has to called first.
It works for CGO3, CGO3+ or CGO-ET.
Attached a part of RC firmware for camera control. Maybe this helps a bit to understand what happen. I remenber, CGO3 should work with CGO3 selection, not with CGO3PRO means you cannot control advances function from ST16 to CGO3. CGO3PRO is only working with CGO3+.
br HE
Someone with CGO3 can use any POST terminal and send this command as a GET request and you'll see the response.
I said in another thread, there is one more feed to the camera for ST16 commands to the copter. Probably you should drive it properly to have a CGO3+ emulation.
I used your q500log2kml program to record the responses to a bunch of commands sent to my CGO3+ camera, then tried to use those in response my ST16 trying to initialize my raspberry pi CGO3 emulator, but still without luck.
I found that if I name my raspberry pi access point CGO3P_123456 then I can select either the CGO3 or CGO3Pro camera from the ST16 without getting the "Wrong camera type selected" error popup, but I can't get either selection to initial.
I can tell that the ST16 is sending the following commands after selecting the camera type:
CMD=INDEX_PAGE
CMD=SET_RTSP_VID&Reslution=720P
CMD=GET_STATUS
It repeats sending the CMD=GET_STATUS command every few seconds.
I also occasionally see a request_bind command when I try clearing and then re-binding the camera and also see a get_bind_state command when I power the controller up the first time.
I'm responding to all of those commands with what I got in response to sending those commands to my CGO3+, but it still won't initialize.
I also tried connecting it to my ST10 and initializing. It looked like the ST10 was sending 3 INDEX_PAGE commands in a row, I'm i'm guessing the ST10 didn't like the response I was giving to that command and kept re-trying it.
My best guesses about the problem are:
1. Even though I think I'm sending the exact same response as I would see from my CGO3+, maybe something is getting garbled or isn't formatted right? (I need to try using your tool to send these commands to my raspberry pi to make sure they responses are coming back correctly)
2. Maybe the ST16 is actually looking at the properties of the RTSP video stream and seeing that they don't exactly match the values in the GET_STATUS response?
Dylan
I'm almost sure it was the 1st problem, the responses weren't being sent correctly. When I tried to connect the q500log2kml program to my raspberry pi CGO3 emulator it wouldn't connect, it said WLAN failed. I then changed how the node.js sends the responses to the commands and then the q500log2kml tool would connect.
After fixing that I got further into the initialization on the ST16, it sent some additional commands (SET_TIME and GET_PANORAMA_STATUS). I'm also getting a "Camera Firmware is too old" message when I bind the camera that I wasn't getting before. I still haven't got to display on the ST16, but I think it is getting closer.
The reason I think it is getting closer to working is that I did get through the initialization and got some blocky video to display on the ST10. So that is progress.
Replace the name with CGO3P_(the last six symbols of the AP's MAC address). I'm almost sure they aren't 123456.
You are right that it isn't named with the MAC address, but I don't think it matters for what I'm doing. But I will fix it and check it out anyway. I'm now getting through the initialization of the raspberry pi configured as a CGO3 with the ST16, I'm just not getting any video. I think it is really close.
Dylan
