3D model for driver cockpit application

Hi Folks,

I am software developer working on the small vehicle with on-board camera which can be controlled over the internet (please see veter-project.blogspot.com for more details). In fact, the first version is ready and I am currently fine-tuning different aspects. This is a pure hobby project, but of course I am going to earn the first million with it soon :slight_smile: . There are two directions I am working on:

  1. Organize commercial races (for money) with such vehicles.
  2. Sell the slower vehicle as a platform for researchers in robotics and computer vision.

To drive the vehicle remotely, there is a Driver Console application which displays video from the on-board camera, provides feedback on user actions (such as steering and acceleration) and display some messages. I’ve attached the screenshot of the current version which I made myself. As you can see, I am not an artist :slight_smile: and this is the reason why I am posting here - I am looking for someone to help me with 3D design of the driver console.

The application is made in such a way, that the whole interface is a 3D scene with named objects which are modified programmatically. For example, there is a plane which is used to place texture on it with video frame or steering wheel is rotated. The whole scene is read from .obj/mtl files which was exported from Blender.

Since this is currently just my hobby completely open-source project, of course, I would prefer to find some volunteers ready to contribute to the project for free. But I am also ready to pay some small amount of money for the work if necessary. In addition, as you can see on the blog, I am trying to promote this project on relevant conferences and of course I will mention the contribution of art work separately.

I hope there is someone with required Blender skills to design a nice driver console and willing to contribute to this project.

Regards,
Andrey.

Attachments


I’ll have a go at this. I’m also into robotics and that sort of thing. (I’ve got an unstoppable (climbs anything) home build 4WD robot that run on a Picaxe)

Should I just make concept art, or do finished models.

What things should I put on the panel:
1)Steering
2)Speed
3)Battery power left?
4)Tilt
5)Anything else? what sensors do you have that you want the information displayed?

How long do I have to make the model(s)? Do you even still want it?

Oh, and I’ll do it for free

Great! Thank you very much for the interest and help offering!

Well… What I need is the 3D model which is exportable to COLLADA format and has the required set of interface elements. The higher quality the better of course. But since it is a hobby project, just feel free to invest the amount of efforts you think is appropriate. Maybe you can get better feeling of what can be done by taking a look at that:
blender-3d.ru/forum/index.php/topic,171.0.html
blender-3d.ru/forum/index.php/topic,171.15.html
(this is a Blender forum in Russian where I posted the similar request, but you can just take a look on images in this thread).
In addition, if it would be helpful, I can provide my currently used .blend file.

Most examples mentioned above are oriented towards the car cockpit. However, in addition to the car, I am also have a small tank (as pictured here: veter-project.blogspot.com) and planning to develop a quad-copter. So what might be interesting is to design the dashboard which is less specific for the car but has more abstract sci-fi robot-like interface. For example, there should not necessarily be the steering wheel in classical sense. Instead some indication of the direction would be enough. For example something like light stripe which is highlighted from the middle to the left or right depending on the driving direction.

Since there will be more then one possible model of the cockpit, I am currently working on software part to support “skins”. So depending on which type of vehicle is currently controlled and user preferences, it would be possible to select different skins for the cockpit.

Just a few words about the interaction between the 3D model of the cockpit and my application. To “animate” the model the program is searching for the objects with well known names in the scene and modify them. For example, to display the video frame, I am looking for the plane with the name “video_plane” and then applying the video frame as a texture to this frame. Similar is for the steering - I am searching for the object called “steering_wheel” and then rotating it depending on the user input.

Originally, I was thinking that it would be great to get just one more or less reasonable dashboard, so I did not implement a lot of flexibility here. That was also the reason for choosing Wavefrong .obj file format. However, since I receive more then one response to my call for contribution the idea of skins was born. I am currently in process of moving to COLLADA file format which enables much more generic integration between 3D models and the program.

There are parts which are always present and those which are optional. The always present parts are:

  • Plane where video from on-board camera is displayed (as a texture).
  • Moving direction indication (I am intentionally not calling it steering wheel here).
  • Speed indication (also do not want to call it tachometer since it could be also just a row of light stripes or whatever else).
  • Plane for messages. This is the placeholder (and background) to indicate where I should place the text messages. Text is placed slightly on top of this plane and string length’s are restricted to fit into the plane width and height.

Optional parts are queried during the initialization and depending on what is actually installed on the vehicle could be:

  • barometer, thermometer, sonar, compass, battery power metter,
  • GPS - requires square place to show the map with current location (I am using openstreetmap.org for it).
  • orientation in space (gyros+accelerometers) - here I was thinking about small, schematic representation of the controlled vehicle which will be rotated around all three axis to represent the current spatial orientation of the vehicle.

So probably that there should be some free space on the screen (dashboard) where available elements could be dynamically added as necessary. The space should be enough to have the complete set of sensors mentioned above.

When I am thinking about the interface I am always getting pictures similar to those from movies about hackers or robots. There are panels with permanently scrolled unreadable text, some led-like indicator stripes and of course video :slight_smile: . In general, I think the Descent-like interface would be great. Another interesting example of such unconventional interface I know is XBMC PC media center xbmc.org/skins/ .

No pressure here. Just go with your own pace. I am working on this project mainly over the nights and weekends and unfortunately it does not progress as fast as I would like it to be. So again - absolutely no time pressure here.

That’s always great to hear! :slight_smile: Thank you!

I know that there are more details need to be clarified, but this post is already quite long and I do not want to scary out the readers with even longer one. So please feel free to ask any remaining questions. I would be glad to clarify them.

P.S.
BTW, folks, does anybody know why I could not post any URLs here? If I try to mark the url using corresponding url button in the editor, the post gets rejected…

You can’t post URLs because you only have two posts. You need around 5 or 10 (i think) to be able to use URLs.

Just a few words about the interaction between the 3D model of the cockpit and my application. To “animate” the model the program is searching for the objects with well known names in the scene and modify them. For example, to display the video frame, I am looking for the plane with the name “video_plane” and then applying the video frame as a texture to this frame. Similar is for the steering - I am searching for the object called “steering_wheel” and then rotating it depending on the user input.
So are the displays constrained to rotation, or can I have a slider for some things? Also is the rotation constrained to the X-axis, or can I have the direction displayed on a Z-axis rotation object? (more like a ribbon compass used in aircraft)

No pressure here. Just go with your own pace. I am working on this project mainly over the nights and weekends and unfortunately it does not progress as fast as I would like it to be. So again - absolutely no time pressure here.
Good to know. It should take me a day per concept, and then another few days to act on any improvements/changes you want.

I would also like to know the aspect ratio of the camera, so I can size the video_plane correctly

I think the Descent-like interface would be great
Hmm, well, I played Descent 2 yesterday…

Here’s one concept:



Any items (except the arcs) can be removed or replaced without degrading from the look too much.
The compass down the bottom can be removed if the input isn’t there, but the outline of it and the central bar stay. When you turn the bar moves ~1cm to the side in which you’re turning.

The map is a print-screen from openstreetmap
the sonar is from Google images.
All other items are made by me
I will add text under the relevant display to make it more obvious to the user what each one shows.

Any thoughts?
What rendering method are you using? does it support a “wireframe” shading mode? and does it support transparency?

There are no constraints regarding rotation axis and sliders are also well possible. In general, any types of joints and constraints which could be exported to COLLADA (.dae) file should be possible. I know very little about what current version of Blender can actually do in this area, but this page gives a hope: wiki.blender.org/index.php/Dev:Source/Physics/Rigid_Body

Video frame size is 640x480.

Somehow, I’ve got the feeling that you like Descent :wink: . Me too.

Cool! I like it! :slight_smile: Thanks for such a quick response!

Here are some comments.

It looks like this sonar is rotating 360 degree one. What I have is much simpler fixed ultra-sound sonar which can measure the distance withing it’s cone-like field of view. So probably something similar to this would be more appropriate:

Yes, that would be great.

I am also want to make sure that we have common understanding about the orientation display (the icon in the top left corner). Will it be a 3D object which could be rotated around all axis to display the spatial orientation?

When I was thinking how to display it, I made the drawing illustrated by the attachment (I’ve also attached the .blend file). This sphere with four “arms” is supposed to schematically represent the quad-copter (without propellers). It should rotate depending on angles reported by the sensors. I am in no way trying to say that it should be done in that way :slight_smile: . It is just an example to illustrate what I am talking about.

Another point to think about is whether to overlay controls over the video or place them around? As I mentioned in my previous posting, the maximum video size is 640x480. So there is a lot of free space remaining on the screen. I am totally agree that overlay approach looks cool. However, from the pure usability point of view, some elements cover parts of the video without real need. Strictly speaking, placing control elements over the video is the way to provide more information using less space. But in this particular case there is no strict need for it. But again, on-the-video controls just look good, so I have absolutely nothing again placing them over there. It was just thoughts I had when thinking about the layout of display elements. Please feel free to place them as you like.

I am using OpenGL directly for visualization. So I have full control how to visualize things. The only things which I should check is how it will be specified in the collada file. I am currently migrating from wavefront .obj to collada and there are a lot of things which are new for me there. But even if there is no direct way to specify it in collada, it is always possible to add some extension information which I can process. So I think you can assume that wireframe shading is possible.

Attachments


console.blend (674 KB)

I am aware that this isn’t really a 3D cockpit, just an overlay, but, I thought it looked cool enough.

It looks like this sonar is rotating 360 degree one. What I have is much simpler fixed ultra-sound sonar which can measure the distance withing it’s cone-like field of view. So probably something similar to this would be more appropriate:
www.langzeittest.de/bmw-3er-touring/intern/grafik/jb-pdc-vorn-hinten.jpg

I am anticipating you replacing the two planes down the bottom (GPS and Sonar) with the data from your sensors. Those images are just place holders, so it doesn’t matter what they look like. But I will see if I can replace that image with a better one.

I am also want to make sure that we have common understanding about the orientation display (the icon in the top left corner). Will it be a 3D object which could be rotated around all axis to display the spatial orientation?

Yes, it is 3D. It could also be replaced with a similar lo-detail model for the quad copter

the maximum video size is 640x480

Yeah, I was hoping it would be a bit more (I didn’t see it in the higher posts) because an overlay only really works with higher res.
I think for my other concepts i will stick with more “dashboard” style, as it works better with lower resolution

Good to know about wireframe, as it was used in a few places here.

It is! :slight_smile: I am also think that it is not absolutely necessary to try to build the classical looking 3D cockpit. It is more important to make it looks cool. :slight_smile:

It is true for the map but not quite true for sonar. The map will be completely replaced (placed as a texture). With sonar it is more difficult. I have to know how exactly to display the data. The only thing I am getting from the sonar is the floating point value indicating the range in the field of view measured by sonar. So I have to decide how to visualize this value. The simplest way for me would be to modify some 3D object in the scene (it’s size, color, orientation, duplicate objects, or whatever else) depending on the measured distance. So maybe you can suggest some ideas how it can looks like.

Great. Then I leave it to you to decide how this object will looks like :slight_smile: . I think something more or less abstract will be good since it will fit for any types of vehicles.

Sure, it would be great to have larger video. But I can drive the vehicle over the Internet and network bandwidth is the main reason for this size. Based on my experience, video latency should be below one second to make driving more or less comfortable. The larger frame size introduces larger latency, so I am currently stick with 640x480.

It should be post #7.

I am really do not want to influence your decisions. So please feel free to do it as you like. It was just an information for consideration from my side.

It is true for the map but not quite true for sonar. The map will be completely replaced (placed as a texture). With sonar it is more difficult. I have to know how exactly to display the data. The only thing I am getting from the sonar is the floating point value indicating the range in the field of view measured by sonar. So I have to decide how to visualize this value. The simplest way for me would be to modify some 3D object in the scene (it’s size, color, orientation, duplicate objects, or whatever else) depending on the measured distance. So maybe you can suggest some ideas how it can looks like.

OK, I’ve just made some changes so now the sonar is shown by the scale of two arcs infront and behind an icon of the vehicle.
How is sonar going to work on the quad-copter, or is it not going to be there?

One last thing I would like to know is the names I should give objects. Are there any names you have assigned to them in code? I know you asked for the background to be called video_plane. Are there any other ones with set names?

I’ve now made some changes. The main one is the aspect ratio of the screen, to fit in with the 640x480 resolution.
Also the sonar has changed, text has been added and the indicating arrows have been moved to possible positions. I will put them back in rest position in the exported objects.



No I wouldn’t recommend driving it at that angle…

Here’s another concept (you can still comment on the first one if you want)
Still need to add in some more somethings (dials, meters etc) to display the remaining information.



The display showing the sky is the camera’s image. The map is, well, the map. The black display with status written on it is for text, and possible some other sensor information (seeing as you are going to show some dynamic text, I may put temperature and altitude in that display).

Looks good. I think it would be easy for me to modify the arcs to represent the measured distance.

It will be pointed down to the earth and will be used for automated landing (the range is withing couple of meters).

Since I am currently doing a lot of modifications related to the migration to the collada format, it is very easy for me to change names. So feel free to name them as you like and I will adjust the code correspondently.

Despite the fact that the first concept looks pretty cool, I am afraid that from the usability point of view the second concept might be better. However, I would not completely throw away the first one. The reason is the chances that sometime I will probably port this application to some small device (I have Nokia n900 phone which might be very good platform for it). In this case, there would not be so much space on the screen and then the idea with overlayed control elements will definitely make sense. But I have to admit that it is not my first priority right now. I want to make it work good on PC/Notebook first and then maybe port to some small devices. So I would proposse to concentrate on the second concept which looks pretty good.

Right. This was my first question when I took a look at the image withot reading the text :slight_smile: . At least driving direction and speed indicator would be nice to have.

I am not sure that putting some information which is supposed to be permanently visible to the message pane will work good. The problem is that new text will scroll the “older” content up. So maybe it would make more sense to separate the pure text message pane from other sensor information? What do you think about it?

It will be pointed down to the earth and will be used for automated landing (the range is withing couple of meters).

Good, thanks.

Since I am currently doing a lot of modifications related to the migration to the collada format, it is very easy for me to change names. So feel free to name them as you like and I will adjust the code correspondently.

Ok, I’ll give them reasonable names (without spaces)

Despite the fact that the first concept looks pretty cool, I am afraid that from the usability point of view the second concept might be better…propose to concentrate on the second concept which looks pretty good.

That’s what I thought, and why I stopped on the first one. I’ll still give you the first one, but I’ll put more effort into the second.

I am not sure that putting some information which is supposed to be permanently visible to the message pane will work good. The problem is that new text will scroll the “older” content up. So maybe it would make more sense to separate the pure text message pane from other sensor information? What do you think about it?

I was planning to divide the plane into two halves, one for the messages, and one for the readouts. I’ll see how it all turns out, I may or may not keep them together.

I’ve added in another 2 panels too display the other information.
Almost ready I think.


Thank you very much for the work! It looks good to me! Here are some thoughts and comments.

Maybe it is just me, but somehow I feel like the wood-style background fall apart slightly from “high-tech” looking panels. Maybe it would be possible to see some alternative textures to compare?

Regarding indicators like temperature, etc. - do you have an experience with rigid bodies and constraints in Blender? The reason I am asking is the following. I will need to modify the position of the indicator programmatically. For this, I will need to know what are allowed movement directions and in what range. I have seen, that collada format supports constraints which are exactly what I need in this case. So I am wondering if Blender can model and export this information?

Maybe it is just me, but somehow I feel like the wood-style background fall apart slightly from “high-tech” looking panels. Maybe it would be possible to see some alternative textures to compare?
Sure, I’ll try some different textures there

Regarding indicators like temperature, etc. - do you have an experience with rigid bodies and constraints in Blender? The reason I am asking is the following. I will need to modify the position of the indicator programmatically. For this, I will need to know what are allowed movement directions and in what range. I have seen, that collada format supports constraints which are exactly what I need in this case. So I am wondering if Blender can model and export this information?

I know blender can do constraints (world location, distance from object, track etc) but have no idea if the collada exporter for blender supports constraints. I will have to look around. If it does then I am happy to put them in. If it doesn’t, well, then there’s no point me putting them in.

Unfortunately it doesn’t seem that the exporter exports constraints. I have run a few tests (exporting and then re-importing the created file) and the constraints vanish, so I am assuming that it doesn’t export them.